Category: Project-Based Learning

A strong spreadsheet portfolio project should show more than a polished dashboard or a list of formulas. It should help a reviewer understand the problem you chose, the decisions you made, how the workbook works, what you tested, and where the project still has limits.

In this project, you will build a simple planning workbook for presenting an original spreadsheet project. The workbook includes a project brief, an evidence map, a case-study outline, documented checks, a failure-and-repair record, and a version history.

By the end, you will have a clear way to connect every portfolio claim to something a reviewer can inspect.

What the finished portfolio-planning workbook includes

The downloadable workbook contains three main working areas:

• Project Brief: the problem, primary skill, features the project will not include, completion definition, and data source.
• Evidence Map: each portfolio claim, the supporting file or workbook location, the check used to verify it, its status, and any limitation.
• Case Study Outline: prompts for explaining the problem, constraints, build, failure, tests, and next version.

The practice example uses an inventory-tracking project for a made-up community workshop. It demonstrates stable item identifiers, movement-based stock calculations, visible error handling, and safe practice data.

Use the accompanying Spreadsheet Portfolio Project workbook to plan and document your project. It includes made-up practice information, an evidence summary, writing prompts, instructions, documented checks, a failure-and-repair example, and version history.

Workbook note: The file contains no real client, employer, or personal information. Make a separate copy before adding your own work. Remove confidential data, hidden comments, outside-file links, and unsupported claims before sharing a portfolio file publicly.

Choose a problem, not a feature list

Start with a decision or workflow that a spreadsheet can improve.

Compare these two project descriptions:

• Weak: A workbook that uses formulas, charts, and PivotTables.
• Stronger: A workbook that helps a community workshop track supply movements and identify items that need review for replenishment.

The stronger version explains who the workbook helps and what it helps them do. The formulas and charts then support that purpose.

Complete the project brief

The Project Brief sheet defines the project before you write the case study.

Field	Practice example
Problem	Help a made-up community workshop monitor inventory shortages.
Primary Skill	Relational spreadsheet design and checking that totals match.
Features this project will not include	Purchasing, accounting, live integrations, and live deployment.
Completion	The workbook works, documented checks pass, supporting files can be reviewed, and limitations are visible.
Data	Made-up practice data only.

Keeping the boundaries visible prevents the project from expanding into a large application that you cannot finish or explain.

Use the BUILD Proof Method

The Learn By Projects BUILD Proof Method gives you a practical sequence for turning a spreadsheet into a credible case study:

1. Bound: define the problem, intended user, required features, and exclusions.
2. Use: work with safe, controlled data that you are allowed to share.
3. Implement: build the smallest complete workflow that solves the stated problem.
4. Log: keep the checks, failures, repairs, and important changes.
5. Deliver: provide enough supporting material for another person to inspect the result.

This sequence keeps the project focused on decisions and evidence rather than visual polish alone.

Make the project your own

Using a tutorial to learn a technique is reasonable. Publishing a near-copy with different colors is not a strong original project.

Change several meaningful parts:

• The problem being solved
• The made-up or authorized data
• The workbook structure
• The constraints and exclusions
• The formulas or workflow
• The error-handling approach
• The documented checks
• The final explanation

Credit tutorials, documentation, templates, or other sources that materially influenced the work. Explain what you changed and why.

Build the smallest complete workflow

A smaller workbook that works is stronger than a large workbook with unclear logic.

For the practice inventory example, the central workflow is:

1. Create one row per item in an item list.
2. Record each opening balance, receipt, use, return, or correction.
3. Calculate quantity on hand from the movement history.
4. Compare quantity on hand with the reorder point.
5. Flag negative quantities and items that need review.

Purchasing, accounting, barcode scanning, supplier management, and live integrations remain outside the project.

Map every claim to evidence

The Evidence Map connects what you say in the case study with something a reviewer can inspect.

Portfolio claim	Evidence location	Evidence check	Status	Limitation
Uses unique identifiers	Inventory workbook Item Master	No duplicate SKU check	Verified	Made-up example
Calculates stock from movements	Inventory workbook Stock Summary	Source and summary totals match	Verified	No live integration
Handles errors visibly	Failure Log	Recovery check	Verified	One documented failure
Protects private data	README and privacy review	Privacy check	Verified	Made-up data only

If the case study says the workbook prevents duplicate IDs, show the entry rule or duplicate check. If it says totals match, point to the zero-difference result. If you cannot identify supporting evidence, rewrite or remove the claim.

Document one real failure

A useful case study does not pretend that every formula worked on the first attempt.

Document:

• What you expected
• What happened instead
• How you found the problem
• What caused it
• What you changed
• Which checks you repeated afterward

For example, a stock total may fail because one movement uses the wrong SKU. Correcting the SKU and repeating the source-to-summary check creates stronger evidence than simply stating that the workbook works.

Show the checks that matter

Your project should include checks that match its main risks. Depending on the workbook, that may include:

• A complete practice example
• A smallest, largest, first, last, or exact-limit value
• An incorrect entry
• A source-to-summary total check
• A formula-recovery check
• A privacy review
• A handoff check with another reader

Keep failed checks in the history. Record the repair and the later passing result rather than deleting the failure.

Write the case study in a clear order

The Case Study Outline uses six sections:

1. Problem: What decision or workflow needed improvement?
2. Constraints: What was intentionally left out?
3. Build: What structure, formulas, and controls did you choose?
4. Failure: What broke, and how was it repaired?
5. Checks: What passed, and what remains uncertain?
6. Next Version: What would you improve next?

Lead with the problem and the result. Do not begin with a list of Excel functions.

Prepare the files a reviewer needs

A useful spreadsheet case study can include:

• A public-safe copy of the workbook
• A short README
• A field or data dictionary
• A few original screenshots
• A documented check record
• A failure-and-repair note
• A version history
• Known limitations
• Attribution for important sources

Use screenshots that prove something: the finished result, the workbook structure, and a check or correction. Avoid decorative screenshots that do not add information.

Make only claims you can support

A made-up project can show your method, spreadsheet structure, formulas, testing approach, and communication. It cannot prove results that were never measured in a real setting.

Do not claim:

• A real client when there was none
• Revenue, savings, or productivity impact that was not measured
• Employment, certification, or credentials you do not have
• Production use when the workbook was only a learning project
• Guaranteed compatibility with every spreadsheet program

Use accurate wording such as “built with made-up practice data,” “designed to demonstrate,” or “tested against the included examples.”

Protect information before sharing

Before publishing a workbook, check for:

• Names, email addresses, phone numbers, or account numbers
• Employer, client, or customer information
• Hidden sheets, rows, or columns
• Comments, notes, or document properties
• Outside-file links and data connections
• Macros that are not required or reviewed
• Local file paths or usernames
• Old versions inside the shared package

Open the public copy separately and inspect what a reviewer will actually receive.

Try five practical checks

Check	What to do	Expected result
Evidence map	Review every portfolio claim.	Each claim points to a file, sheet, cell, screenshot, or documented check.
Known limitation	Look for at least one visible limitation.	The case study explains what the project does not prove.
Unsupported claim	Try to add a result that was not measured.	The claim is removed or rewritten accurately.
Claim count	Compare the evidence map with the case-study claims.	Every material claim has supporting evidence.
Handoff	Ask another person to follow the README.	The reviewer can understand the workbook and repeat the main example.

Choose a spreadsheet project

If you need a project idea, choose one that demonstrates the decisions and skills you want a reviewer to understand.

• Build a personal expense tracker to demonstrate transaction tables, category controls, budget comparisons, and matching totals.
• Build a weekly project dashboard to demonstrate connected project records, milestones, risks, and deadline checks.
• Build an inventory tracker to demonstrate stable identifiers, movement history, reorder logic, and corrections.
• Build a data-cleaning workbook to demonstrate source preservation, cleaning rules, exceptions, and row-count checks.
• Build a monthly reporting template to demonstrate stable measure definitions, target comparisons, and recovery steps.
• Build a task-prioritization sheet to demonstrate scoring, dependencies, capacity, and transparent manual decisions.
• Build a form-response analysis workbook to demonstrate response-count rules, distributions, comment coding, and privacy review.
• Build a basic forecast model to demonstrate assumptions, planning cases, monthly calculations, and model checks.
• Build a reusable checklist system to demonstrate evidence-based review, structured feedback, and revision history.

Common mistakes to avoid

• Starting with a feature list: Begin with the user and problem.
• Copying a tutorial: Change the problem, data, structure, decisions, and checks.
• Listing formulas without explaining choices: Show why the structure fits the problem.
• Deleting failed checks: Keep the failure, repair, and passing result.
• Publishing private information: Create and inspect a public-safe copy.
• Claiming unmeasured impact: Limit claims to what the evidence supports.
• Hiding limitations: A clear boundary makes the project more credible.

What this project helps you practice

This project gives you experience with project scoping, safe data, evidence mapping, case-study structure, documented checks, failure analysis, privacy review, attribution, and honest claims. It also gives you a repeatable way to turn a spreadsheet into a case study another person can understand and inspect.

Microsoft Excel references

• Microsoft Support: Create and format tables
• Microsoft Support: Make Excel documents accessible
• Microsoft Support: Check workbook compatibility

A checklist works best when each item helps you prevent a specific mistake. Vague reminders such as “make it professional” or “double-check everything” sound responsible, but different reviewers can interpret them in completely different ways.

In this project, you will build a reusable Microsoft Excel checklist system for reviewing spreadsheet projects. The workbook includes a 12-item checklist library, a completed review run, evidence fields, a feedback-decision table, a completion summary, and a record of how one weak checklist item was improved.

By the end, you will have a checklist you can reuse without changing the history of earlier reviews. You will also have a practical way to decide whether feedback should be accepted, deferred, or declined.

What the finished checklist system includes

The downloadable workbook contains three main working areas:

• Checklist Library: the reusable list of review items and the evidence required for each one.
• Run Log: the result, evidence, reviewer, and reason for every item in one completed review.
• Feedback Decisions: a record connecting reviewer feedback to the decision and resulting revision.

The practice review contains 12 checklist items. The completed run records 10 Pass results, 1 Blocked result, and 1 Not Applicable result.

Use the accompanying Reusable Checklist System workbook to follow the project and inspect the finished setup. It includes made-up practice records, drop-down controls, summary formulas, structured feedback, instructions, documented checks, a failure-and-repair example, and version history.

Workbook note: The file uses made-up practice information that contains no real personal or business data. Make a separate copy before adapting it to your own review process. Check the items, evidence requirements, permissions, and compatibility before using it for live work.

Start with the failure each item should prevent

Before writing a checklist item, ask what could go wrong. A useful item addresses a clear, observable problem.

For example, this item is weak:

The workbook looks professional.

A reviewer cannot apply that item consistently because “professional” is subjective. A stronger version is:

Every chart has a descriptive title, a labeled unit, and a matching data range recorded in the evidence field.

The revised item tells the reviewer what to inspect and what evidence to record.

Write items that can be checked

A strong checklist item usually contains three parts:

1. An action: review, confirm, compare, calculate, or inspect.
2. An object: a chart, formula, total, input field, README, or data table.
3. Evidence: the cell, screenshot, sheet, test result, or written note that supports the answer.

Compare these examples:

Weak item	Stronger item
Check the totals.	Compare the source total with the summary total and record a difference of zero.
Make labels clear.	Confirm that every input has a descriptive label and unit.
Check privacy.	Confirm that the shared copy contains no names, email addresses, account numbers, hidden comments, or outside-file links.
Test the workbook.	Run the documented normal, incorrect-value, limit-value, and recovery checks.

Build the checklist library

The Checklist Library keeps the reusable items separate from any single review. Each row contains:

• Item ID
• The check to perform
• The evidence required
• Whether the item applies only in certain situations
• Whether the item is active

The practice library includes these 12 checks:

1. Every sheet has a descriptive name.
2. Core totals match the source.
3. Every chart has a descriptive title and unit.
4. Private information is absent.
5. Input cells have clear labels and units.
6. Required inputs use entry controls where practical.
7. Incorrect values are blocked or visibly flagged.
8. The main workflow produces the expected result.
9. Limit values behave as documented.
10. A failed calculation can be restored.
11. The README explains how to use the workbook.
12. Known limits are stated clearly.

Keep item IDs stable. If you rewrite an item later, the ID helps you trace which version was used in an earlier review.

Keep each completed review separate

The Run Log records what happened during one review. It should not replace the reusable checklist library.

Each result row includes:

• Run ID
• Item ID
• Result
• Evidence
• Reason when the item does not apply
• Reviewer

The result drop-down includes Pass, Fail, Blocked, and Not Applicable.

Use the choices consistently:

• Pass: the requirement is met and the evidence is recorded.
• Fail: the requirement is not met.
• Blocked: the reviewer cannot complete the check because required information or access is missing.
• Not Applicable: the item does not apply to this project, and the reason is recorded.

Understand the 12-item practice run

The completed example produces:

• 10 Pass results
• 0 Fail results
• 1 Blocked result
• 1 Not Applicable result

The summary formulas use COUNTIF to count each result. COUNTIF is an Excel function that counts cells matching a condition.

The Pass formula follows this pattern:

=COUNTIF(RunLog[Result],"Pass")

The workbook also calculates a resolved rate:

=IFERROR((Pass+NotApplicable)/(Pass+Fail+Blocked+NotApplicable),0)

In the practice run, 11 of the 12 items are resolved, producing a resolved rate of about 91.7%. The Blocked item prevents the review from being treated as fully complete.

Require evidence, not only a check mark

A Pass result should point to something another reviewer can inspect. Depending on the item, useful evidence may include:

• A sheet name
• A cell showing a zero difference
• A screenshot
• A test ID
• A privacy-review note
• A version-history entry
• A link to a safe supporting file

If an item requires evidence and the field is blank, the item should not be closed as Pass.

Ask for feedback in a useful format

Unstructured comments such as “I do not like this” are difficult to evaluate. Ask reviewers to provide:

• The checklist item ID
• The issue they observed
• The evidence supporting the observation
• The severity or effect
• The suggested change
• Whether the issue prevents completion

This does not make the reviewer responsible for the final decision. It gives the project owner enough information to assess the feedback.

Decide what to do with feedback

The Feedback Decisions sheet records whether feedback is accepted, deferred, or declined.

Decision	When it fits
Accepted	The feedback identifies a real issue and the project will be changed.
Deferred	The feedback is useful but belongs in a later version or requires more information.
Declined	The feedback does not fit the project scope, conflicts with evidence, or would create a larger problem.

Record the reason for every decision. Feedback is important input, but it is not an automatic instruction.

Improve the checklist after each use

After a review, look at the checklist itself.

Ask:

• Which items were difficult to interpret?
• Which items duplicated another check?
• Which items were repeatedly marked Not Applicable?
• Which real problems were not detected?
• Which evidence requirements were too vague?
• Which items added work without changing a decision?

Revise, combine, or remove weak items. A longer checklist is not automatically a better checklist.

Keep completed reviews unchanged

When you improve the Checklist Library, do not rewrite the results of earlier runs. The completed review should continue to show the item wording, result, evidence, and decision that applied at that time.

This is why the reusable library and the Run Log are separate. One can improve without erasing the other.

Try five practical checks

Check	What to do	Expected result
Complete run	Record a result for all 12 checklist items.	The summary shows 10 Pass, 1 Blocked, and 1 Not Applicable.
Not Applicable item	Select Not Applicable for an item that does not fit.	A reason is recorded.
Missing evidence	Try to close an evidence-based item without an evidence reference.	The review process keeps the item open or identifies the missing evidence.
Library update	Rewrite a checklist item after completing a run.	The earlier run remains unchanged.
Feedback trace	Follow one reviewer comment to its decision and revision.	The connection is clear in Feedback Decisions.

Customize the checklist system

After you understand the practice workbook, make a copy and adapt it carefully.

• Replace the practice items with checks tied to real mistakes you want to prevent.
• Give every item a stable ID.
• State the evidence required for Pass.
• Define when an item can be Not Applicable.
• Keep the checklist library separate from completed runs.
• Record accepted, deferred, and declined feedback.
• Review the summary formulas after adding result choices.
• Remove items that add work without improving the review.

The workbook is a completed learning example rather than an approval platform. It does not assign permissions, collect signatures, prevent every invalid result, or replace accountable review.

Common mistakes to avoid

• Writing subjective items: “Looks good” is difficult to verify.
• Using check marks without evidence: A result should point to something reviewable.
• Mixing the master list with completed runs: Template changes should not rewrite history.
• Forcing every item to apply: Use Not Applicable with a reason when appropriate.
• Accepting every comment automatically: Record a decision and reason.
• Adding items after every mistake: Improve weak items before making the checklist longer.
• Ignoring blocked items: A blocked check may prevent the review from being complete.

What this project helps you practice

This project gives you experience with reusable checklist libraries, evidence requirements, result controls, COUNTIF, IFERROR, completed-run history, structured feedback, and revision decisions. It also shows how a checklist can become more useful through repeated testing and improvement.

Continue the project workflow

• Apply the checklist to monthly reporting when the same report is prepared repeatedly.
• Use the checklist to review a spreadsheet portfolio project when you want to confirm the workbook, tests, limitations, and supporting files are ready to share.

Microsoft Excel references

• Microsoft Support: Create and format tables
• Microsoft Support: COUNTIFS function
• Microsoft Support: Make Excel documents accessible

A basic forecast helps you explore what could happen when a few important assumptions change. It does not predict the future with certainty. Its value comes from making the assumptions visible, carrying the calculations forward consistently, and showing how the result changes under different planning cases.

In this project, you will build a 12-month Microsoft Excel forecast for a made-up subscription service. The model begins with 100 customers, adds new customers each month, subtracts customers who leave, and calculates monthly revenue.

By the end, you will have base, downside, and upside planning cases, a month-by-month customer schedule, a revenue calculation, model checks, and a decision log explaining the choices behind the forecast.

What the finished forecast includes

The downloadable workbook contains three main working areas:

• Assumptions: the starting customer count, monthly additions, monthly churn rate, price, and selected planning case.
• Forecast: a 12-month schedule showing beginning customers, additions, churned customers, ending customers, price, and revenue.
• Decision Log: the assumption or choice, alternatives considered, reason selected, and signal that would cause an update.

The practice workbook includes three planning cases:

Planning case	Starting customers	Monthly additions	Monthly churn	Price
Base	100	12	5%	$25
Downside	100	8	8%	$23
Upside	100	16	3%	$27

Use the accompanying Basic Forecast Model workbook to follow the project and inspect the finished setup. It includes made-up practice assumptions, working formulas, planning-case controls, a customer chart, model checks, a decision log, instructions, documented checks, a failure-and-repair example, and version history.

Workbook note: The file uses made-up practice assumptions and contains no real customer information. It is provided for educational and general informational use. Review every assumption, formula, limitation, and compatibility issue before adapting it to real financial or business decisions.

Start with the question the forecast should answer

Before entering assumptions, decide what the model is for. A useful question for this project is:

How could customer count and monthly revenue change over the next 12 months under three different planning cases?

This keeps the model focused. It does not attempt to forecast cash flow, expenses, taxes, payment timing, customer segments, annual contracts, or profit.

Keep assumptions separate from formulas

Open the Assumptions sheet. Inputs should be easy to find and change without editing the forecast formulas.

For each assumption, record:

• The value
• The unit, such as customers, percentage, or dollars per month
• The planning case
• Why the value was chosen
• What new information would cause it to change

The workbook uses a drop-down to select Base, Downside, or Upside. The forecast formulas use INDEX and MATCH to retrieve the assumptions for the selected case.

A planning case is a consistent set of assumptions. It is not a probability unless you have separately estimated and supported the likelihood of that outcome.

Build the monthly customer schedule

The Forecast sheet uses one row per month. Each row contains:

• Beginning Customers
• New Customers
• Churned Customers
• Ending Customers
• Price
• Revenue
• A calculation check

The customer calculation is:

Beginning customers + new customers – churned customers = ending customers

The formula follows this pattern:

=MAX(0,B6+C6-D6)

MAX prevents the displayed customer count from falling below zero. It does not correct a poor assumption, so unusually high churn should still be reviewed.

Work through the first base-case month

The Base planning case starts with:

• 100 beginning customers
• 12 new customers
• 5% monthly churn
• $25 monthly price

The workbook rounds churned customers to a whole number:

100 × 5% = 5 churned customers

The ending customer count is:

100 + 12 – 5 = 107 ending customers

The revenue calculation uses ending customers multiplied by price:

107 × $25 = $2,675

This is a deliberate simplification. A more detailed model might use average customers during the month, daily billing, contract start dates, or deferred revenue. The Decision Log explains why the simpler method was selected for this learning project.

Carry the ending value into the next month

Month two should begin with the 107 customers from month one. Each later month follows the same pattern: the prior month’s ending customers become the next month’s beginning customers.

The workbook advances the date with EDATE:

=EDATE(A6,1)

EDATE moves the date forward by one calendar month. This avoids the uneven results that can occur when a model adds a fixed number of days to represent a month.

Compare the three planning cases

Each planning case should tell a coherent story.

• Base: moderate additions, moderate churn, and the middle price.
• Downside: fewer additions, higher churn, and a lower price.
• Upside: more additions, lower churn, and a higher price.

Do not change assumptions randomly just to make the chart look different. Explain why the values move together and what real information would support the case.

The workbook displays one selected case at a time. Change the selection on the Assumptions sheet, then review the customer schedule and chart.

Run a one-assumption-at-a-time check

A useful forecast should respond in the expected direction when an assumption changes.

Start with the Base case, then change only monthly churn from 5% to 8% in a copy. Leave starting customers, additions, and price unchanged.

You should expect:

• More customers to leave each month
• Lower ending-customer counts
• Lower monthly revenue

If the result does not move in that direction, the assumption may be disconnected from the formulas or a reference may be wrong.

After the check, restore the original value or close the test copy without saving.

Use model checks

The final column confirms that the customer calculation works:

=IF(B6+C6-D6=E6,"OK","FAIL")

Review the model if a row displays FAIL. Also look for:

• Negative prices
• Churn below 0% or above 100%
• Missing assumptions
• Broken links between months
• Negative new-customer values unless they have a clearly defined meaning
• Numbers displayed with more precision than the assumptions justify

Document decisions, not just numbers

The Decision Log explains the choices behind the workbook. The practice version records:

• Why Base monthly additions are set to 12
• Why Base monthly churn is set to 5%
• Why the model uses ending customers multiplied by price

For each important choice, record:

1. The assumption or method
2. The alternatives considered
3. The reason for the selected approach
4. The new information that would trigger an update

This makes the forecast easier to revise when better information becomes available.

Avoid false precision

A forecast built from rough assumptions should not appear more certain than those assumptions allow.

• Use whole customers when partial customers have no practical meaning.
• Use sensible currency rounding.
• Do not label a planning case with a precise probability unless that probability has been estimated separately.
• Display limitations near the result rather than hiding them in a note.

The model is a planning tool. It does not guarantee customer growth, revenue, retention, market demand, or business performance.

Try five practical checks

Check	What to do	Expected result
First base month	Use 100 starting customers, 12 additions, and 5% churn.	Ending customers equal 107.
No change	Set additions and churn to zero in a copy.	The customer count remains stable.
Invalid churn	Try to enter a churn rate above 100%.	The input rule blocks or warns about the value.
Monthly calculation	Check beginning plus additions minus churn.	The result matches ending customers and displays OK.
Higher churn	Raise churn while holding the other assumptions constant.	Ending customers and revenue decline.

Customize the forecast

After you understand the practice workbook, make a copy and adapt it carefully.

• Replace the practice assumptions with values supported by your own evidence.
• Update the Decision Log when an assumption changes.
• Keep assumptions separate from formulas.
• Add checks for values that should not be negative.
• Use planning-case names that readers can understand.
• Confirm that later months begin with the prior month’s ending value.
• Review the chart after changing the forecast period.
• State what the model leaves out.

The workbook is a completed learning example rather than a complete financial model. It does not include expenses, taxes, cash timing, customer acquisition cost, contract terms, profit, or financing.

Common mistakes to avoid

• Mixing assumptions with formulas: Keep editable inputs visible and separate.
• Calling planning cases probabilities: A downside case is not automatically a 25% outcome.
• Using hidden hardcoded values: Readers should be able to find every important assumption.
• Breaking the month-to-month link: The next month should begin with the prior month’s ending value.
• Changing several assumptions during a single check: Change one at a time when you want to understand cause and effect.
• Showing false precision: Match the displayed precision to the quality of the inputs.
• Treating the forecast as a promise: Results depend on the assumptions and may not occur.

What this project helps you practice

This project gives you experience with separated assumptions, drop-down case selection, INDEX and MATCH, monthly customer calculations, EDATE, IF checks, charts, one-assumption-at-a-time review, and decision logs. It also shows how clear limitations make a forecast more useful rather than less useful.

Continue the project workflow

• Start with a reliable monthly reporting template when historical results should inform the forecast assumptions.
• Prioritize decisions from the forecast cases when the model reveals several possible actions.
• Present the forecast model responsibly if you want to explain the assumptions, formulas, checks, and limitations.

Microsoft Excel references

• Microsoft Support: Calculate multiple results by using a data table
• Microsoft Support: IFERROR function
• Microsoft Support: Create and format tables

A form can collect useful feedback quickly, but the exported responses still need careful review. Blank answers, invalid ratings, changing question labels, and personal information can all distort the analysis.

In this project, you will build a Microsoft Excel workbook for 30 made-up workshop-feedback responses. You will preserve the original responses, define what each question means, summarize ratings and topic choices, separate comment coding from the source data, and confirm that every response is counted correctly.

By the end, you will be able to explain how many people were eligible to answer each question, how many supplied a valid response, and which records need attention.

What the finished analysis workbook includes

The downloadable workbook contains four main working areas:

• Responses: the original 30 practice responses.
• Question Dictionary: the response type, allowed values, missing-answer meaning, and analysis rule for each question.
• Analysis: the response counts and checks for the rating question.
• Comment Coding: a separate table for grouping optional comments into a small set of themes.

The practice example includes 27 valid ratings, 2 missing ratings, and 1 invalid rating. Those values add back to the 30 eligible responses.

Use the accompanying Form-Response Analysis workbook to follow the project and inspect the finished setup. It includes made-up practice responses, working formulas, entry controls, a response-audit chart, comment coding, instructions, documented checks, a failure-and-repair example, and version history.

Workbook note: The file uses made-up practice data that contains no real personal information. Make a separate copy before adding your own responses. Remove names, email addresses, private comments, and other identifying details before sharing an analysis workbook.

Begin with a few answerable questions

Before building summaries, decide what you need to learn from the responses. For this project, the workbook answers five practical questions:

1. How many responses were eligible for the rating question?
2. How many ratings were valid?
3. How many ratings were missing?
4. How many ratings were outside the allowed range?
5. What broad themes appear in the optional comments?

This focused scope prevents the workbook from becoming a large survey-analysis system. It also makes every result easier to check.

Preserve the response table

Open the Responses sheet. Keep one row per response and do not rewrite the original values during analysis.

Field	What it contains
Response ID	A stable identifier such as R001, R002, or R003.
Timestamp	The date associated with the practice response.
Rating	A whole number from 1 to 5, a blank, or the deliberately invalid value 7.
Topic	Formulas, Charts, or Cleaning.
Comment	An optional short response such as Useful practice, More examples, or Clear steps.

The workbook uses data validation for new rating and topic entries. Data validation is an Excel rule that limits what someone can enter in a cell. Existing imported data can still contain invalid values, so the analysis must check the source rather than assuming every record is valid.

Define each question before analyzing it

The Question Dictionary explains how each field should be treated.

Field	Response type	Allowed values	Missing answer means	Analysis rule
Rating	Whole number	1 to 5	No rating was supplied	Count only values from 1 through 5 as valid
Topic	Choice	Formulas, Charts, or Cleaning	No topic was selected	Count each approved choice
Comment	Text	Free text	No comment was supplied	Code themes separately while preserving the original response

This step matters because a blank rating, an invalid rating, and a valid low rating are not the same thing.

Count the valid ratings

The workbook uses COUNTIFS to count ratings that are at least 1 and no more than 5. COUNTIFS is an Excel function that counts records meeting more than one condition.

The formula follows this pattern:

=COUNTIFS(Responses[Rating],">=1",Responses[Rating],"<=5")

In the practice data, this returns 27 valid ratings.

The workbook also counts blank ratings and calculates invalid ratings:

• Eligible responses: 30
• Valid ratings: 27
• Missing ratings: 2
• Invalid ratings: 1

Check that the response counts match

The most important count check is:

Valid + missing + invalid = eligible responses

For the practice workbook:

27 valid + 2 missing + 1 invalid = 30 eligible responses

The Analysis sheet includes a difference check. The expected difference is zero. If it is not zero, a response may have been counted twice, excluded, or assigned to the wrong group.

Do this check separately for each question. A person can answer one question and skip another, so the valid-response count may differ from question to question.

Show distributions, not only averages

An average can hide important differences. Two rating sets can have the same average even when one group is consistently satisfied and another is split between very low and very high ratings.

When you adapt the workbook, report:

• The valid-response count
• The number or percentage for each rating from 1 to 5
• The number of missing and invalid responses
• The average only when it adds useful context

Always display the valid-response count near the result. “Average rating: 4.2 based on 27 valid responses” is clearer than “Average rating: 4.2.”

Keep comment coding separate

The Comment Coding sheet copies the Response ID and original comment into a separate working table. The source Responses sheet remains unchanged.

The practice workbook uses four theme choices:

• Useful practice
• Requests more examples
• Clear instructions
• Unclear

Use Unclear when a comment does not fit the approved themes. Do not force every response into a category simply to make the counts look complete.

A small hand-coded theme list can describe the practice responses. It should not be presented as a universal conclusion, automated sentiment result, or statement about what respondents intended.

Protect privacy before sharing

A public analysis should contain only what readers need to understand the method and result.

Remove or replace:

• Names
• Email addresses
• Phone numbers
• Employee or customer identifiers
• Private free-text comments
• Links that reveal restricted files or systems

If the source comments contain sensitive details, create a safe summary rather than publishing the original text.

Try five practical checks

Check	What to do	Expected result
Complete response set	Load all 30 practice responses.	The eligible-response count is 30.
Valid rating count	Count ratings from 1 through 5.	The valid-rating count is 27.
Invalid rating	Keep the supplied rating of 7 in the imported source.	It is counted as invalid rather than valid.
Response-count check	Add valid, missing, and invalid ratings.	The result equals 30 and the difference is zero.
Privacy review	Inspect the version prepared for sharing.	No names, email addresses, or private comments remain.

Customize the workbook for your form

After you understand the practice example, make a copy and adapt it carefully.

• Replace the practice responses with a safe copy of your own export.
• Do not edit the original response values during analysis.
• Update the Question Dictionary for every field you plan to summarize.
• Define valid, missing, and invalid values before counting responses.
• Create a separate coding table for comments.
• Review formulas and chart ranges after adding rows.
• Recheck every question using its own valid-response count.
• Remove personal information before sharing the file.

The workbook is a completed learning example rather than a full survey platform. It does not collect responses, identify people, infer emotions, perform validated sentiment analysis, or establish statistical significance.

Common mistakes to avoid

• Using one response count for every question: Missing answers can differ by question.
• Counting an invalid option as valid: Check values against the documented allowed range.
• Editing the source during analysis: Keep correction and coding work in separate tables.
• Reporting an average without a distribution: The average can hide disagreement.
• Forcing every comment into a theme: Keep an Unclear choice.
• Treating themes as proven intent: Comment coding is an organized interpretation, not mind reading.
• Sharing identifiable responses: Remove private information before distributing the analysis.

What this project helps you practice

This project gives you experience with Excel Tables, response rules, data validation, COUNTIFS, blank and invalid-value handling, response-count checks, distributions, comment coding, and privacy review. It also shows why careful counting matters as much as the final chart or average.

Continue the project workflow

• Clean form-response data before analysis when dates, categories, or text values are inconsistent.
• Turn survey measures into a monthly report when the same form is reviewed every month.
• Present the response analysis as a spreadsheet project if you want to explain the counting rules, privacy controls, and comment-coding decisions.

Microsoft Excel references

• Microsoft Support: COUNTIFS function
• Microsoft Support: Create and format tables
• Microsoft Support: Apply data validation to cells

A long task list does not tell you what to do first. A useful prioritization sheet helps you compare work consistently, notice what is blocked, and separate important work from work that is actually ready to start.

In this project, you will build two connected views in Microsoft Excel. The first uses a simple score based on impact, urgency, and effort. The second adds project-level constraints such as strategic fit, dependencies, required dates, capacity, and risk.

By the end, you will have a transparent ranking method, a Ready Now check, and a portfolio view that shows why the highest-scoring task may not be the next task you can perform.

What the finished prioritization workbook includes

The downloadable workbook contains these main working areas:

• Tasks: the task list, input scores, calculated priority, dependencies, risk, and Ready Now result.
• Scale Definitions: plain-language descriptions of what each 1-to-5 score means.
• Portfolio View: a compact comparison of score, strategic fit, required date, capacity, risk, and readiness.

The practice example contains three tasks. Task A has an impact score of 5, urgency of 4, and effort of 2. The example formula gives it a calculated score of 12. However, Task A is blocked and has an unresolved dependency, so it does not appear as ready to start.

Use the accompanying Task-Prioritization Sheet to follow the project and inspect the finished setup. It includes made-up practice data, working formulas, score controls, portfolio fields, instructions, documented checks, a failure-and-repair example, and version history.

Workbook note: The file uses made-up practice data that contains no real personal information. Make a separate copy before adding your own tasks. Review the score definitions, formulas, permissions, and compatibility before using the workbook for live business decisions.

Start with the simple scoring model

The simple version uses three inputs:

• Impact: How much useful value could the task create?
• Urgency: How strongly does timing affect the task?
• Effort: How much work is required?

Each input uses a whole-number scale from 1 to 5. The workbook calculates priority with this formula:

=Impact*2+Urgency-Effort

In the Tasks sheet, the corresponding formula for the first practice row is:

=I6*2+J6-K6

Impact receives twice the weight of urgency, while effort reduces the score. This is a teaching model, not a universal formula. The weights should reflect the decisions you are trying to make.

Define the scoring scale

A score is only useful when people apply it consistently. Keep the definitions visible on the Scale Definitions sheet.

Input	Low end	High end
Impact	1: Small local benefit	5: Major objective supported
Urgency	1: Can wait	5: Immediate time constraint
Effort	1: Small effort	5: Large effort

Do not assign scores based only on instinct. Use the written definitions and add a short note when a score needs explanation.

Work through the Task A example

Task A uses these inputs:

• Impact: 5
• Urgency: 4
• Effort: 2

The calculation is:

(5 × 2) + 4 – 2 = 12

Now change one input at a time:

• If effort rises from 2 to 3, the score falls from 12 to 11.
• If impact falls from 5 to 4, the score falls from 12 to 10.
• If urgency rises from 4 to 5, the score rises from 12 to 13.

This check shows whether the formula behaves in the direction you expect. If a more difficult task becomes more attractive when effort rises, the formula may not match your intent.

Add portfolio constraints

A score is helpful, but it does not capture every reason a task may need to wait. The portfolio version adds these fields:

Field	What it adds
Strategic Fit	How closely the task supports the current objective.
Dependency	Work or access that must be completed first.
Required Date	A real deadline or time constraint.
Capacity Needed	The amount of available effort the task requires.
Risk	The consequence or uncertainty associated with the task.

The Portfolio View places these constraints next to the calculated score. This makes it easier to explain why a lower-scoring task may be the better immediate choice.

Separate priority from readiness

The highest-scoring task is not always ready to start. A task may be blocked by missing access, an unfinished dependency, unavailable capacity, or a required decision.

The practice workbook uses this readiness formula:

=IF(OR(Blocked="Yes",Dependency<>"None"),"No","Yes")

In the first practice row, the formula checks the Blocked and Dependency fields. Task A scores 12, but it is blocked and depends on data-source access. Its Ready Now result is therefore No.

This distinction helps prevent a ranked task list from becoming a misleading work queue.

Use a clear tie-break rule

Two tasks can receive the same score. Decide how ties will be handled before they occur.

A simple tie-break order is:

1. Earlier required date
2. Higher strategic fit
3. Lower effort or capacity need
4. Lower risk
5. Oldest task or another clearly documented rule

Do not resolve ties silently. A visible rule makes the ranking easier to explain and repeat.

Handle manual priority changes carefully

Sometimes a person needs to change the calculated order. For example, a legal deadline, customer commitment, safety issue, or executive decision may outweigh the scoring model.

If you make a manual priority change, record:

• The original calculated score
• The new position or decision
• The reason for the change
• Who approved it
• The date of the decision

Keep the calculated score visible. The goal is not to prevent judgment. It is to make the judgment understandable.

Review tasks in a useful order

Use the workbook in this sequence:

1. Check new tasks. Confirm that each task has enough information to score.
2. Review blocked tasks. Identify the dependency, owner, and next step.
3. Inspect Ready Now tasks. Compare score, required date, capacity, and risk.
4. Look for stale work. A high-scoring task that never moves may have an unresolved constraint.
5. Review manual changes. Confirm that the reason still applies.

The score organizes attention. It does not replace capacity planning, deadlines, dependencies, or accountable judgment.

Try five practical checks

Check	What to do	Expected result
Task A score	Enter impact 5, urgency 4, and effort 2.	The calculated score is 12.
Effort change	Raise Task A effort from 2 to 3 in a copy.	The score falls from 12 to 11.
Equal scores	Create two tasks with the same score.	The documented tie-break rule determines the order.
Blocked task	Mark the highest-scoring task as blocked.	It remains high priority but shows Ready Now as No.
Formula recovery	In a copy, replace one score formula and then restore it.	The correct score and ranking return.

Customize the prioritization sheet

After you understand the practice workbook, make a copy and adapt it carefully.

• Rewrite the 1-to-5 definitions for your work.
• Adjust the score weights only when you can explain why.
• Add real required dates rather than using urgency as a substitute for every deadline.
• Use specific dependency descriptions.
• Define what each capacity score means.
• Keep Ready Now separate from the calculated score.
• Review formulas and summary ranges after adding tasks.
• Keep a reason for every manual priority change.

The workbook is a completed learning example rather than a full resource-management system. It does not assign people automatically, measure actual capacity, predict delivery dates, or make final business decisions.

Common mistakes to avoid

• Using a formula no one can explain: A simpler model is often easier to trust and maintain.
• Treating urgency as value: A task can be urgent without being important.
• Ignoring dependencies: High priority does not mean ready to start.
• Changing scores to force a preferred answer: Record a manual decision instead.
• Comparing unlike scales: Use the same definitions across the task list.
• Leaving ties unresolved: Publish a clear tie-break rule.
• Ranking more work than capacity allows: Use the Portfolio View to consider what can actually be started.

What this project helps you practice

This project gives you experience with weighted scoring, 1-to-5 input controls, IF and OR formulas, dependencies, readiness checks, required dates, capacity, risk, and transparent manual decisions. It also shows why a priority score should support judgment rather than replace it.

Continue the project workflow

• Display priorities in a weekly project dashboard when the selected work needs regular status review.
• Review priorities with a repeatable checklist when several people score or approve work.
• Present the prioritization model as a spreadsheet project if you want to explain the scoring logic, constraints, and manual decisions.

Microsoft Excel references

• Microsoft Support: Create and format tables
• Microsoft Support: Apply data validation to cells
• Microsoft Support: Sort data in a range or table

A monthly report should make it easy to see what changed, how the current results compare with the target, and what needs attention next. It should not require you to rebuild the same calculations or explain the same measures from scratch every month.

In this project, you will build a Microsoft Excel reporting template for three practice measures: completed work, backlog, and quality rate. The workbook includes monthly inputs, clear measure definitions, a one-page report, a data-quality checklist, and a simple recovery process for broken formulas.

By the end, you will have a reusable reporting structure that compares the current month with the prior month and the target while keeping the underlying definitions consistent.

What the finished monthly report includes

The downloadable workbook contains four main working areas:

• Monthly Inputs: one row for each reporting month.
• Metric Dictionary: plain-language definitions for every measure.
• Report: current results, prior results, targets, differences, and a comparison chart.
• Data Quality Checklist: five checks to complete before sharing the report.

The practice example covers August, September, and October 2026. October reports 184 completed items, a backlog of 23, and a quality rate of 97.2%.

Use the accompanying Monthly Reporting Template to follow the project and inspect the finished setup. It includes made-up practice data, working formulas, target comparisons, a chart, instructions, documented checks, a failure-and-repair example, and version history.

Workbook note: The file uses made-up practice data that contains no real personal information. Make a separate copy before adding your own measures. Review formulas, definitions, permissions, and compatibility before using the workbook for live business reporting.

Define each measure before building the report

A report becomes unreliable when the meaning of a measure changes from one month to the next. Before creating formulas or charts, write down what each measure means, how it is calculated, and whether a higher or lower value is better.

Measure	Meaning	Unit	Target	Preferred direction
Completed	Items completed during the month	Count	175	Higher is better
Backlog	Open items at the end of the month	Count	20	Lower is better
Quality Rate	Valid completions divided by reviewed completions	Percentage	96.0%	Higher is better

Keep these definitions on the Metric Dictionary sheet. If a definition changes, record the change rather than silently comparing unlike results.

Enter one row for each month

The Monthly Inputs sheet stores one row per reporting period. The practice workbook includes:

Month	Completed	Backlog	Quality Rate
August 2026	165	24	95.5%
September 2026	175	20	96.0%
October 2026	184	23	97.2%

Use real Excel dates for the Month column and format them as month and year. A date such as October 1, 2026 can display as October 2026 while still behaving like a date in formulas and charts.

Do not overwrite the prior month when the next month begins. Add a new row so the history remains visible.

Compare current, prior, and target values

The Report sheet brings the current month, prior month, and target into one view. Each row answers a slightly different question:

• Completed: Did total output reach the target?
• Backlog: Did open work remain at or below the desired ceiling?
• Quality Rate: Did quality meet the minimum target?

For October 2026:

• Completed is 184, which is 9 above the target of 175.
• Backlog is 23, which is 3 above the desired ceiling of 20.
• Quality Rate is 97.2%, which is 1.2 percentage points above the 96.0% target.

The workbook uses different difference formulas because the preferred direction changes by measure. For Completed, the formula is:

=B6-D6

For Backlog, lower is better, so the formula is:

=D7-B7

Label the column clearly and explain the sign convention. A positive number should have a consistent meaning for the reader.

Separate the result from the explanation

The workbook can show that completed work increased, backlog rose, or quality exceeded the target. It cannot determine why those changes occurred unless you provide supporting evidence.

Use the comment guide to answer three questions:

1. What changed?
2. What evidence supports the explanation?
3. What action follows?

For example, “Backlog increased from 20 to 23” is a measured result. “Backlog increased because two team members were absent” is an explanation that needs supporting evidence.

Handle a zero prior value carefully

Percentage change can become misleading when the prior value is zero. Dividing by zero creates an error, and replacing that error with 0% suggests no change when the values may have changed substantially.

A safer formula uses IFERROR:

=IFERROR((Current-Prior)/ABS(Prior),"Not comparable")

IFERROR returns a fallback value when a formula produces an error. In this case, “Not comparable” is clearer than an infinite percentage or a misleading 0%.

Use the data-quality checklist

Before sharing the monthly report, complete the five checks on the Data Quality Checklist sheet:

1. One row exists for the selected reporting month.
2. Completed and backlog values are whole numbers at or above zero.
3. Quality Rate is between 0% and 100%.
4. Current, prior, target, and difference formulas are present.
5. Comments separate measured results from explanations that still need support.

The checklist is short on purpose. Each item confirms something that can materially affect the report.

Recover a broken reporting month

Keep a clean starting copy before entering the first month. Then practice recovery in a separate copy:

1. Replace one difference formula with an incorrect value.
2. Confirm that the report or checklist exposes the problem.
3. Restore the formula from the clean starting copy.
4. Recheck the current, prior, and target values.
5. Record what broke and how it was repaired.

This is more useful than assuming formulas will never be changed. A simple recovery process reduces the impact of an accidental edit.

Try five practical checks

Check	What to do	Expected result
Complete month	Enter the October values.	The report shows 184 completed, 23 backlog, and 97.2% quality.
Zero prior value	Set a prior value to zero in a copy.	The percentage comparison displays Not comparable.
Incorrect value	Enter text in a count field or a percentage above 100%.	The review process identifies the entry.
New month	Add another reporting month.	Prior months remain unchanged and available for comparison.
Formula recovery	Replace and then restore one report formula in a copy.	The correct result returns after restoration.

Customize the template for your measures

After you understand the practice workbook, make a copy and adapt it carefully.

• Replace the three measures with your own clearly defined measures.
• State the unit for every measure, such as count, dollars, hours, or percentage.
• Record whether higher or lower is better.
• Set targets outside the formulas so they can be reviewed and updated.
• Add one row for each reporting month.
• Update the Report formulas and chart ranges when you add measures.
• Keep the comments separate from measured results.
• Save a clean starting copy before changing the template.

The workbook is a completed learning example rather than an automated reporting platform. It does not import data, verify source systems, explain causes, approve business decisions, or protect every formula from being edited.

Common mistakes to avoid

• Changing definitions between months: A trend is not meaningful when the underlying measure changes.
• Hardcoding targets inside formulas: Keep targets visible so they can be reviewed.
• Overwriting the prior month: Add a new row instead.
• Using red, yellow, and green without words: Pair color with a clear status label.
• Forcing a percentage change when the prior value is zero: Use Not comparable.
• Turning assumptions into facts: Separate measured results from explanations.
• Sharing before checking the inputs: Complete the data-quality checklist first.

What this project helps you practice

This project gives you experience with structured monthly inputs, stable measure definitions, current-versus-prior comparisons, target differences, IFERROR, simple charts, data-quality checks, and formula recovery. It also shows how a consistent template can make a recurring report easier to review and maintain.

Continue the project workflow

• Start with a weekly project dashboard when the underlying work needs frequent status review.
• Add a focused forecast to the report when you want to explore possible future results.
• Build a monthly reporting checklist when several people prepare or review the report.
• Present the reporting template as a spreadsheet project if you want to explain the definitions, comparisons, and recovery process.

Microsoft Excel references

• Microsoft Support: IFERROR function
• Microsoft Support: Create and format tables
• Microsoft Support: Create a chart from start to finish

Messy data does not always need a complicated solution. If a contact list has extra spaces, inconsistent capitalization, invalid dates, unknown categories, or possible duplicates, a small Excel workbook can help you clean it without changing the original source.

In this project, you will build a data-cleaning workbook for 20 made-up practice records. You will preserve the raw data, document each cleaning rule, create a cleaned table, and send questionable records to a separate review list instead of guessing.

By the end, you will have 18 cleaned records, 2 records that need review, and a clear check showing that all 20 source records are still accounted for.

What the finished data-cleaning workbook includes

The downloadable workbook contains four main working areas:

• Raw Data: the untouched source records.
• Transformation Map: a table showing how each source field will be cleaned.
• Clean Data: records that passed the documented rules.
• Exceptions: records that need a person to review them.

The practice example focuses on five manageable cleaning tasks:

• Remove extra spaces from names.
• Remove nonprinting characters from text.
• Convert recognizable date text into Excel dates.
• Keep only approved category values.
• Separate records with invalid or unknown values for review.

Use the accompanying Data-Cleaning Workbook to follow the project and inspect the finished setup. It includes made-up practice data, working formulas, a field-cleaning map, an exceptions sheet, instructions, documented checks, a failure-and-repair example, and version history.

Workbook note: The file uses made-up practice data that contains no real personal information. Make a separate copy before adding your own records. Review formulas, privacy, permissions, and compatibility before using the workbook with real information.

Keep the scope small enough to finish

Data cleaning can grow into a much larger project if you try to solve every possible problem at once. For this workbook, keep the first version limited to a few rules you can explain and check.

A realistic first scope is:

1. Trim extra spaces.
2. Remove nonprinting characters.
3. Convert valid date text into real Excel dates.
4. Accept only the approved categories A, B, and C.
5. Move impossible dates and unknown categories to the review list.

This project does not try to identify people across different systems, fill missing values, decide whether similar names represent the same person, or make automatic corrections when the right answer is unclear.

Preserve the raw data

Open the Raw Data sheet. It contains 20 practice records with a Record ID, Raw Name, Raw Date, and Raw Category.

Do not clean the only copy of the source. Keeping the raw records unchanged gives you a reference point when a cleaned value looks wrong or when a rule needs to change.

A useful raw-data sheet should include:

• A stable record ID for every row
• The original values exactly as received
• A note describing where the data came from
• The number of source rows
• No manual cleanup inside the source columns

The practice workbook uses 20 source rows. Two contain deliberate problems: one impossible date and one category that is not on the approved list.

Document each cleaning rule

The Transformation Map explains what will happen to each field. This prevents undocumented cleanup and makes the results easier to review.

Output field	Source field	Cleaning rule	What happens when the value fails
Clean Name	Raw Name	Remove extra spaces and nonprinting characters while preserving punctuation.	Send blank or unusable names to review.
Clean Date	Raw Date	Convert recognizable date text into an Excel date.	Send impossible dates to review.
Clean Category	Raw Category	Accept A, B, or C.	Send unknown categories to review.

Write the rule before changing the data. If the rule is hard to explain in one or two sentences, it may be too broad for the first version.

Clean the name field

The workbook uses TRIM and CLEAN together. TRIM removes extra spaces from text, while CLEAN removes many nonprinting characters.

The formula follows this pattern:

=TRIM(CLEAN('Raw Data'!B6))

This is useful for names with spaces before or after the text. It should not remove meaningful punctuation such as apostrophes or hyphens.

For example:

• Alex Stone becomes Alex Stone.
• JORDAN-LEE keeps its hyphen.
• Sam O'Neil keeps its apostrophe.

Capitalization is a separate decision. Do not automatically convert every name to title case unless you have checked how that rule handles initials, prefixes, acronyms, and intentionally styled names.

Convert recognizable date text

The workbook uses DATEVALUE to convert recognizable date text into an Excel date value.

The formula follows this pattern:

=DATEVALUE('Raw Data'!C6)

A date such as 2026-10-05 can be converted and then displayed with a consistent date format. An impossible value such as 2026-99-99 should not be guessed or silently replaced. It belongs on the Exceptions sheet.

Date interpretation can vary by regional settings. If your source uses formats such as 03/04/2026, confirm whether the value means March 4 or April 3 before converting it.

Control category values

The practice workbook accepts categories A, B, and C. The Raw Data sheet includes a drop-down for these values, but the cleaning process must still account for unexpected source values.

If a record contains UNKNOWN, do not force it into A, B, or C. Keep the original value and send the record to the Exceptions sheet with a reason.

This approach makes uncertainty visible. It also prevents an incorrect category from looking like a confirmed decision.

Separate clean records from exceptions

The Clean Data sheet contains the 18 records that meet the documented rules. The Exceptions sheet contains two records that need review:

Record	Problem	Raw value
R019	Impossible date	2026-99-99
R020	Unknown category	UNKNOWN

The review list is not a failure. It is a control that keeps uncertain values from entering the cleaned table unnoticed.

Check that every row is accounted for

The most important count check is:

Clean records + exception records = raw records

For the practice workbook:

18 clean + 2 exceptions = 20 raw records

If the count does not match, a record may have been lost, duplicated, counted twice, or excluded without explanation.

You can also compare other before-and-after measures:

• Blank names
• Invalid dates
• Unknown categories
• Possible duplicate IDs
• Total source rows

Try five practical checks

Check	What to do	Expected result
Valid records	Run the 18 records that follow the rules.	All 18 appear in Clean Data.
Punctuation	Use a name with a hyphen or apostrophe.	The punctuation remains intact.
Impossible date	Use 2026-99-99 as a source date.	The record appears in Exceptions rather than Clean Data.
Row count	Add clean and exception records.	The result equals the 20 raw records.
Repeat the process	Run the same rules against the unchanged source again.	The workbook produces the same cleaned values and exceptions.

Formula method or Power Query?

The downloadable workbook uses formulas so you can see each cleaning step directly in the cells. This is a good fit for a small learning project with a fixed number of records.

Power Query is Excel’s repeatable data-import and cleaning tool. It may be a better choice when you need to import larger files, repeat the same steps often, combine several sources, or reshape columns and rows.

The workbook does not contain a Power Query query. Power Query is presented as another method you can explore after you understand the cleaning rules.

Customize the workbook for your data

After you understand the practice example, make a copy and adapt it carefully.

• Replace the source records with a safe copy of your own data.
• Update the approved category list.
• Rewrite the field-cleaning map before adding new rules.
• Keep the raw sheet unchanged.
• Add clear reason labels to the Exceptions sheet.
• Confirm that formulas cover every intended row.
• Recheck the row counts after every change.
• Remove personal or confidential information before sharing the workbook.

The supplied formulas cover the practice rows in the workbook. If you add more source records, extend the formulas or convert the working ranges into the structure you plan to maintain.

Common mistakes to avoid

• Cleaning the only source copy: Preserve the raw records first.
• Making manual edits without a rule: A change that cannot be repeated is difficult to review.
• Guessing unknown values: Send uncertain records to the Exceptions sheet.
• Deleting possible duplicates automatically: Similar records are not always duplicates.
• Changing capitalization without checking edge cases: Names and codes may use intentional formatting.
• Reporting improvement without a starting count: Compare before-and-after measures.
• Forgetting the row-count check: Clean records and exceptions should account for every source row.

What this project helps you practice

This project gives you experience with preserving source data, documenting cleaning rules, using TRIM, CLEAN, and DATEVALUE, controlling category values, separating exceptions, and checking that record counts still match. It also shows why uncertain data should remain visible instead of being silently changed.

Continue the project workflow

• Analyze the cleaned response data when your source came from a form or survey.
• Create a reusable data-quality checklist when the same cleaning review will happen more than once.
• Present the data-cleaning workbook as a spreadsheet project if you want to explain the rules, exceptions, and before-and-after checks.

Microsoft Excel references

• Microsoft Support: Use Power Query to transform data
• Microsoft Support: TRIM function
• Microsoft Support: CLEAN function

An inventory tracker helps you answer a simple question: How much of each item do I have right now? A useful tracker should also show which items are running low, where they are stored, and why the recorded quantity changed.

In this project, you will build a Microsoft Excel workbook for three practice inventory items. Instead of typing over the current quantity each time something changes, you will record every opening balance, receipt, use, return, and correction in a stock-movement log. Excel will calculate the quantity on hand from that history.

By the end, you will have an item list, a movement log, a stock summary, reorder alerts, and a clear record of how each quantity was calculated.

What the finished inventory tracker includes

The downloadable workbook contains three main working areas:

• Item Master: one row for each item, including its SKU, unit, location, reorder point, and active status.
• Movements: one row for each opening balance, receipt, use, return, or correction.
• Stock Summary: the calculated quantity on hand, reorder point, and status for each item.

The practice example tracks three items:

• SKU-A ends with 20 units on hand.
• SKU-B ends with 6 units on hand after an opening balance, receipt, use, and correction.
• SKU-C ends with 0 units on hand after all four available units are used.

Use the accompanying Inventory Tracker workbook to follow the project and inspect the finished setup. It includes made-up practice data, working formulas, drop-down controls, a quantity chart, instructions, documented checks, a failure-and-repair example, and version history.

Workbook note: The file uses made-up practice data that contains no real personal information. Make a separate copy before entering your own inventory. Review formulas, units, reorder points, permissions, and compatibility before using the workbook for live business work.

Start with the item master

Open the Item Master sheet. Keep one row per item and give every item a unique SKU. A SKU is a stable identifier that helps Excel connect the item to its stock movements even if the item name changes later.

Field	What to enter
SKU	A unique code such as SKU-A, SKU-B, or SKU-C.
Item	A clear item name such as Fastener Kit or Safety Gloves.
Unit	The measurement used for the item, such as box, pair, pack, or each.
Location	Where the item is stored, such as Shelf A or Shelf B.
Reorder Point	The quantity at which the item should be reviewed for replenishment.
Active	Whether the item is still being tracked.

Do not use the item name as the only identifier. Names can be shortened, corrected, or reused. The SKU should remain stable.

Record every stock movement

Open the Movements sheet. Each row explains one change in quantity.

The practice workbook uses these movement types:

• Opening: the starting quantity when tracking begins.
• Receipt: stock that was received and added.
• Use: stock that was consumed, issued, or removed.
• Return: stock that was returned to inventory.
• Correction: an adjustment made after a physical count or discovered error.

The workbook uses positive quantities for stock coming in and negative quantities for stock going out. For example, a receipt of five units is entered as 5, while use of seven units is entered as -7.

Use one sign convention throughout the workbook. Mixing positive and negative rules makes the quantity on hand difficult to verify.

Understand the SKU-B example

SKU-B shows why a movement log is more useful than typing a current quantity directly into the item list.

Movement	Quantity	Running result
Opening balance	10	10
Receipt	5	15
Use	-7	8
Correction after physical count	-2	6

The final calculated quantity is 6. The correction remains visible, so anyone reviewing the workbook can see why the recorded quantity changed from 8 to 6.

Do not rewrite the earlier receipt or use records to force the total to match. Add a correction with a clear reason instead.

Calculate quantity on hand

The Stock Summary sheet uses SUMIFS, an Excel function that adds values meeting one or more conditions.

The formula follows this pattern:

=SUMIFS(Movements[Quantity],Movements[SKU],A6)

This tells Excel to add every movement quantity connected to the SKU shown in the summary row.

The practice workbook produces these on-hand quantities:

SKU	Item	Quantity on hand	Reorder point	Expected status
SKU-A	Fastener Kit	20	6	OK
SKU-B	Safety Gloves	6	10	Reorder
SKU-C	Cleaning Pads	0	4	Reorder

Add reorder and negative-stock alerts

The status formula compares the calculated quantity with the reorder point:

=IF(C6<0,"Negative stock",IF(C6<=D6,"Reorder","OK"))

The formula returns:

• Negative stock when the calculated quantity falls below zero.
• Reorder when the quantity is at or below the reorder point.
• OK when the quantity remains above the reorder point.

A Reorder result is a prompt to review the item. It is not an automatic purchasing decision. Before ordering, you may still need to consider supplier lead time, minimum order size, expected demand, available storage, budget, and whether the item is still active.

Review the tracker in a useful order

Use the Stock Summary as a starting point, then inspect the underlying records.

1. Check negative quantities first. A negative result may indicate a missing receipt, duplicate use record, incorrect SKU, or timing issue.
2. Review items at or below the reorder point. Confirm that the reorder point still makes sense.
3. Look for unknown or blank SKUs. Every movement should connect to an item in the Item Master.
4. Check units. Do not mix boxes, individual pieces, pairs, or packs without a documented conversion.
5. Review corrections. Each correction should explain what was found and why the change was needed.

Try five practical checks

Check	What to do	Expected result
Normal movement history	Enter the supplied opening balances, receipts, uses, and correction.	SKU-A is 20, SKU-B is 6, and SKU-C is 0.
Exact reorder point	Set an item’s quantity equal to its reorder point.	The status shows Reorder.
Unknown SKU	Try to enter a movement for a SKU that is not approved.	The drop-down or review process prevents or flags the entry.
Quantity check	Add the opening balance and all later movements for one SKU.	The result matches the Stock Summary.
Formula recovery	In a copy, replace one SUMIFS formula and then restore it.	The correct quantity returns.

Customize the tracker for your inventory

After you understand the practice workbook, make a copy and adapt it carefully.

• Replace the three practice items with your own item list.
• Create a unique SKU for every item.
• Use one unit of measure for each SKU.
• Update storage locations and reorder points.
• Add approved SKUs to the movement-entry drop-down.
• Create a Stock Summary row for every added SKU.
• Confirm that new records remain inside the Excel Tables.
• Review formulas and chart ranges after adding items.

The workbook is a completed learning example, not an unlimited inventory application. Adding a new SKU requires updates to the approved SKU list and the summary. It does not automatically handle purchasing, supplier management, barcode scanning, inventory valuation, taxes, or accounting.

Common mistakes to avoid

• Typing current quantity into the item list: This removes the history that explains how the quantity changed.
• Using changing item names as identifiers: Use a stable SKU instead.
• Mixing units: A box and an individual item are not interchangeable unless you document the conversion.
• Editing old movements to fix a count: Add a correction with a reason.
• Allowing duplicate movement IDs: Every movement should have its own identifier.
• Treating Reorder as an automatic purchase: Review demand, timing, cost, and availability first.
• Ignoring negative stock: Investigate the source records before accepting the result.

What this project helps you practice

This project gives you experience with Excel Tables, stable identifiers, drop-down controls, SUMIFS, IF formulas, movement-based calculations, reorder logic, corrections, and quantity checks. It also shows why a visible transaction history is more reliable than repeatedly overwriting a current balance.

Continue the project workflow

• Clean an inventory dataset before importing it when item names, SKUs, units, or dates are inconsistent.
• Report inventory measures each month when you want a recurring view of stock levels and exceptions.
• Turn the inventory tracker into a spreadsheet case study if you want to explain the structure, calculations, and checks behind the workbook.

Microsoft Excel references

• Microsoft Support: Create and format tables
• Microsoft Support: SUMIFS function
• Microsoft Support: Apply data validation to cells

A weekly project dashboard helps you see what needs attention without reading through every task, note, and milestone. A useful dashboard should answer four questions quickly: What changed? What is due soon or late? What is blocked? What needs to happen next?

In this project, you will build a Microsoft Excel dashboard for three practice projects. The workbook includes a project register, seven milestones, a risk register, deadline calculations, blocked-work indicators, and a short weekly review view.

The goal is not to fit every project detail onto one sheet. It is to create a focused review tool that helps you decide where to look and what to do next.

What the finished dashboard includes

The downloadable workbook contains these working areas:

• Projects: one row for each project, including its owner, target date, health, progress, next action, and blocked status.
• Milestones: the major deliverables and dates connected to each project.
• Risk Register: open and closed risks, owners, and response actions.
• Dashboard: a compact view of project health, time remaining, open risks, blocked work, and missing next actions.

The practice example uses three projects and seven milestones. It deliberately includes an overdue project, a project due soon, open risks, blocked work, and a missing next action so you can see how the dashboard flags each condition.

Use the accompanying Weekly Project Dashboard workbook to follow the project and inspect the finished setup. It includes made-up practice data, working formulas, drop-down controls, a chart, instructions, documented checks, a failure-and-repair example, and version history.

Workbook note: The file uses made-up practice data that contains no real personal information. Make a separate copy before adding your own projects. Review formulas, dates, permissions, and compatibility before using the workbook for live business work.

Start with the project register

Open the Projects sheet. Keep one row per project and give every project a unique ID. The ID connects the project to its milestones and risks even if the project name changes later.

Field	What it tells you
Project ID	A stable identifier such as P001, P002, or P003.
Project	The short project name.
Owner	The person responsible for the next update.
Target Date	The planned completion date.
Status	Whether the project is Planned, Active, On Hold, or Complete.
Health	A simple label such as Healthy, Watch, or At Risk.
Progress	A rough percentage for context, not proof of completion.
Next Action	The next concrete step someone should take.
Blocked	Whether something currently prevents progress.

Use the drop-down lists for Status, Health, and Blocked. Consistent labels make the dashboard easier to filter and prevent small wording differences from creating separate groups.

Track milestones separately

A project can have several milestones, so keep milestones on their own sheet rather than adding columns such as Milestone 1, Milestone 2, and Milestone 3 to the Projects sheet.

Each milestone should include:

• A unique milestone ID
• The related project ID
• A clear milestone name
• A due date
• A status such as Open, Complete, Late, or Blocked
• An evidence note when the milestone is complete

The practice workbook includes seven milestones. One is deliberately late so the weekly review has a real exception to surface.

Add a simple risk register

The Risk Register keeps uncertainty separate from current project status. A project can appear active while still carrying one or more open risks.

Record a risk ID, project ID, short description, owner, status, and response action. Keep the response action specific. “Monitor” is usually too vague. “Confirm the approver and decision date” gives the owner something concrete to do.

The dashboard counts open risks for each project with a COUNTIFS formula. COUNTIFS is an Excel function that counts records meeting more than one condition.

The formula follows this pattern:

=COUNTIFS(RiskRegister[Project ID],Projects!A6,RiskRegister[Status],"Open")

Calculate time remaining

The dashboard compares each target date with the review date. In the practice workbook, the review date is November 4, 2026.

A simplified day-count formula is:

=Projects!D6-DATE(2026,11,4)

A positive result means days remain. Zero means the target date is today. A negative result means the target date has passed.

For a reusable version, place the review date in a labeled cell and reference that cell instead of typing the date directly into every formula.

Build the weekly dashboard

The Dashboard sheet should show only what supports the weekly review. The practice version includes:

• Project name
• Health
• Target date
• Days to target
• Blocked status
• Number of open risks
• Whether the next action is ready or missing

The missing-action formula checks whether the Next Action field is blank:

=IF(Projects!H6="","Missing","Ready")

This prevents a project from looking complete merely because it has a status and progress percentage. If there is no next action, the weekly review should make that visible.

Run a five-minute weekly review

Use the same review sequence each week:

1. Start with late dates. Identify projects and milestones whose target dates have passed.
2. Review blocked work. Confirm the blocker, owner, and next step.
3. Check open risks. Look for risks without a useful response action.
4. Find missing next actions. Every active project should have a concrete next step.
5. Confirm what changed. Update project health, milestones, and notes only when the underlying information changed.

The dashboard succeeds when a reviewer can identify the most urgent item within five minutes. In the practice example, the Inventory Cleanup project should receive attention because its target date has passed, it is blocked, it has an open risk, and its next action is missing.

Do not rely on progress percentage alone

Progress percentages are useful context, but they are often subjective. One person may call a project 80% complete while another would call the same work 50% complete.

Use milestones, dates, evidence, blockers, and next actions as stronger signals. A completed milestone with a link or note showing what was delivered is more useful than an unsupported percentage.

Try five practical checks

Check	What to do	Expected result
Complete example	Load the three projects, seven milestones, and three risks.	All records appear in their working sheets and dashboard results.
Due today	Set a target date equal to the review date.	Days to target shows zero rather than late.
Missing next action	Leave one active project’s Next Action blank.	The dashboard displays Missing.
Open risk count	Add an open risk for one project.	That project’s open-risk count increases by one.
Formula recovery	In a copy, replace one dashboard formula and then restore it.	The correct project flag returns.

Customize the dashboard

After you understand the practice workbook, adapt a copy to your own projects.

• Replace the three project rows with your own projects.
• Update the status and health choices if your team uses different terms.
• Add milestones with stable project IDs.
• Record only risks that need attention or a response.
• Use one labeled review-date cell for reusable calculations.
• Confirm that added rows remain inside the Excel Tables.
• Review chart ranges and formulas after adding projects.

Keep the dashboard small enough to review quickly. If a field does not change a decision or prompt a useful question, it may belong in a supporting sheet rather than on the dashboard.

Common mistakes to avoid

• Putting projects and milestones in one table: This creates repeated project data and makes summaries harder to maintain.
• Using color without words: Pair colors with labels such as Healthy, Watch, At Risk, or Late.
• Showing every available field: A dashboard is a review surface, not a copy of the full project register.
• Leaving actions vague: “Follow up” is weaker than “Confirm approval with Jordan by Friday.”
• Trusting percentages too much: Use milestone evidence, dates, blockers, and risks to support the status.
• Ignoring the review date: Day counts are only meaningful when the date used by the formula is clear.

What this project helps you practice

This project gives you experience with structured Excel Tables, connected project IDs, date calculations, IF and COUNTIFS formulas, drop-down controls, simple charts, and a repeatable review process. It also shows how to reduce a large amount of project information into a short list of decisions.

Continue the project workflow

• Build a repeatable monthly reporting template when weekly status needs to roll into a broader report.
• Prioritize next actions across projects when several projects compete for limited time.
• Present the dashboard as a spreadsheet project if you want to explain the project structure, formulas, and review logic.

Microsoft Excel references

• Microsoft Support: Create and format tables
• Microsoft Support: Use conditional formatting to highlight information
• Microsoft Support: Create a PivotTable to analyze worksheet data

A personal expense tracker gives you one place to record purchases, organize them by category, and see where your money went during the month. You do not need a budgeting app or a connection to your bank account to build one.

In this project, you will create a straightforward Microsoft Excel workbook with a transaction list, category controls, a monthly summary, and a budget comparison. The downloadable workbook includes made-up practice data so you can inspect the setup before replacing it with your own information.

By the end, you will be able to answer three basic questions: How much did I spend? Which categories accounted for most of it? Did the summary match the underlying transactions?

What the finished expense tracker includes

The workbook has three main working areas:

• Transactions: one row for each purchase or payment.
• Lists: the approved spending categories used by the category drop-down.
• Summary: category totals, budget amounts, differences, and a spending chart.

The example contains 12 practice transactions for October 2026. Together, they total $2,321.10 across Housing, Groceries, Transportation, Utilities, and Personal spending.

Use the accompanying Personal Expense Tracker workbook to follow the project, inspect the formulas, and try the included examples. The workbook also contains instructions, documented tests, a failure-and-repair example, and a version history.

Workbook note: The file uses made-up practice data that contains no real personal information. Make a separate copy before entering your own transactions. Review the formulas, security settings, and compatibility before using the workbook for real financial decisions.

Start with the transaction table

Open the Transactions sheet. Each row represents one transaction, and each column answers a specific question about it.

Column	What to enter
Transaction ID	A unique label such as T001, T002, or T003.
Date	The date the purchase or payment occurred.
Description	A short name such as Rent, Market, Fuel, or Internet.
Category	The spending group selected from the drop-down list.
Amount	The transaction amount using one consistent sign convention.
Account	The account used, such as Checking or Card.
Notes	Optional context that will help you understand the entry later.

Keep one transaction per row. Do not add category totals or monthly summaries inside the transaction table. Separating the source entries from the summary makes the workbook easier to check and less likely to produce accidental double-counting.

Create a category list

The practice workbook uses these categories:

• Housing
• Groceries
• Transportation
• Utilities
• Personal
• Uncategorized

The category column uses data validation, an Excel rule that limits what someone can enter in a cell. Selecting categories from a drop-down prevents small spelling differences such as “Grocery,” “Groceries,” and “grocery” from creating separate totals.

Keep Uncategorized as an available choice. It is better to leave a transaction visibly unfinished than to force it into the wrong category or hide it inside a broad Other category.

Build the monthly summary

The Summary sheet adds the transactions in each category. The workbook uses SUMIFS, an Excel function that adds values that meet one or more conditions.

The category formula follows this pattern:

=SUMIFS(Transactions[Amount],Transactions[Category],A6)

This tells Excel to add values from the Amount column when the transaction category matches the category listed in the summary row.

The October practice transactions produce these results:

Category	Actual spending	Budget	Budget minus actual
Housing	$1,450.00	$1,500.00	$50.00
Groceries	$412.35	$450.00	$37.65
Transportation	$188.40	$220.00	$31.60
Utilities	$176.25	$190.00	$13.75
Personal	$94.10	$100.00	$5.90

A positive result in the final column means money remains in that category. A negative result means actual spending exceeded the category budget. Keep that sign convention visible so the numbers are not misread.

Check that the totals match

The most important accuracy check is simple: the total of the transaction table should equal the total of the category summary.

1. Add all 12 amounts in the Transactions table.
2. Add the category totals on the Summary sheet.
3. Subtract the summary total from the transaction total.
4. Confirm that the difference is $0.00.

In the practice workbook, both totals equal $2,321.10. If the difference is not zero, check for:

• An amount stored as text instead of a number
• A category typed outside the approved list
• A date or transaction accidentally left outside the intended month
• A summary formula that does not include every category
• A row added outside the Excel Table

Review entries that need attention

Before relying on the summary, look for entries that may need correction:

• Blank or Uncategorized categories
• Duplicate transaction IDs
• Dates stored as text
• Zero or negative amounts that do not match your chosen convention
• Unusually large transactions
• Transactions assigned to the wrong account or month

The workbook is a learning example rather than a connected financial application. It does not import bank activity, identify fraud, calculate taxes, or replace professional financial advice.

Try five useful checks

You do not need formal testing experience. Use a few practical checks to make sure the tracker behaves as expected.

Check	What to do	Expected result
Complete month	Load the 12 practice transactions.	The total is $2,321.10.
First and last date	Enter transactions on the first and final day of the month.	Both appear in the correct monthly total.
Incorrect category	Try to enter a category that is not on the approved list.	Excel blocks or warns about the entry.
Total match	Compare the transaction total with the category summary.	The difference is $0.00.
Formula recovery	In a copy, replace one summary formula and then restore it.	The correct total returns after the formula is restored.

Customize the tracker for your own use

Once you understand the practice workbook, make a copy and adjust it carefully.

• Replace the practice transactions with your own entries.
• Change category names to fit your spending.
• Update the category budgets.
• Add accounts such as Checking, Credit Card, or Cash.
• Keep an Uncategorized option for entries that still need review.
• Recheck the totals after adding categories or changing formulas.

If you add a new category, add it to the approved list and create a corresponding row in the summary. If you add many new transactions, confirm that they are inside the Transactions table and included in the formulas and chart.

Common mistakes to avoid

• Mixing entries and summaries: Keep transaction data separate from category totals.
• Using inconsistent signs: Decide whether spending is entered as positive or negative and use that approach throughout.
• Hiding unfinished entries: Leave questionable transactions visible as Uncategorized.
• Trusting a chart before the totals: Confirm the numbers first. A polished chart can still be based on incorrect data.
• Editing formulas without a backup: Make a copy before changing calculation cells.
• Entering sensitive information: Avoid account numbers, passwords, card numbers, or other information the tracker does not need.

What this project helps you practice

This project gives you practical experience with Excel Tables, category drop-downs, SUMIFS, budget comparisons, basic charts, and total checks. More importantly, it shows how a small spreadsheet can turn a list of transactions into information you can review and use.

Continue the project workflow

• Clean inconsistent transaction data when dates, categories, or descriptions need standardization.
• Turn the tracker into a monthly report when you want a repeatable review process.
• Present the expense tracker as a spreadsheet project if you want to show the decisions, formulas, and checks behind the workbook.

Microsoft Excel references

• Microsoft Support: Create and format tables
• Microsoft Support: SUMIFS function
• Microsoft Support: Apply data validation to cells