Activity: Create a Weekly Project Report
Activity Overview
This activity helps learners practice creating a clear, structured, and professional weekly project report. A weekly project report is one of the most useful communication tools in project management because it gives stakeholders a regular view of project progress, current status, risks, issues, blockers, decisions needed, and next steps.
In this activity, learners will work with a practical project scenario and prepare a weekly report using a standard format. The purpose is not only to fill a template, but also to learn how to communicate project information in a way that is useful, concise, accurate, and action-oriented.
By completing this activity, learners will understand how a team lead can collect weekly updates, organize them into report sections, highlight important risks and issues, and communicate next steps with clear ownership.
Activity Purpose
The purpose of this activity is to help learners convert raw project updates into a meaningful weekly project report. Many project updates are scattered across meetings, emails, chats, task trackers, and team conversations. A weekly project report brings this information together in one structured format.
A good weekly project report should help stakeholders answer these questions:
- What is the current project status?
- What was completed this week?
- What is currently in progress?
- What is planned for next week?
- What risks or issues need attention?
- What blockers or dependencies exist?
- What decisions or support are needed?
- Who owns the next actions?
- When will the next update be shared?
This activity gives learners a practical way to answer these questions in a professional report format.
Learning Objectives
After completing this activity, learners will be able to:
- Create a structured weekly project report.
- Summarize weekly accomplishments clearly.
- Identify planned work for the next reporting period.
- Communicate risks, issues, blockers, and dependencies professionally.
- Use Green, Amber, and Red status indicators with explanation.
- Write client-friendly and leadership-friendly project updates.
- Assign clear owners and due dates for action items.
- Convert vague updates into specific project report statements.
- Use reporting to improve transparency and accountability.
- Prepare a report that supports decision-making and timely action.
When to Use This Activity
This activity can be used in a classroom session, leadership communication workshop, project management training, team lead onboarding, or professional development program.
It is especially useful after learners have studied:
- What project reporting is.
- The purpose of project reporting.
- Key elements of a project report.
- Communicating risks and issues.
- Reporting without blame.
- Communicating with clients.
- Communicating with internal leadership.
Activity Duration
Recommended duration: 45 to 60 minutes.
| Activity Part | Recommended Time | Purpose |
|---|---|---|
| Scenario Review | 5 minutes | Understand the project context and available information. |
| Report Drafting | 15 minutes | Create the first version of the weekly project report. |
| Risk and Issue Review | 10 minutes | Check whether risks, issues, owners, and impact are clear. |
| Group Discussion | 10 minutes | Compare different report versions and discuss improvements. |
| Final Rewrite | 10 minutes | Improve the report using feedback and best practices. |
Activity Instructions
Learners should complete this activity step by step. The goal is to create a weekly report that is clear, structured, and useful for stakeholders.
- Read the project scenario carefully.
- Identify the project status based on available information.
- List the key accomplishments from the week.
- List work currently in progress.
- Identify planned work for the next week.
- Identify risks, issues, dependencies, and blockers.
- Write action items with owner and due date.
- Prepare a final weekly project report using the template provided.
- Review whether the report is clear, professional, and action-oriented.
- Rewrite weak or vague statements into stronger project reporting language.
Project Scenario
Read the scenario below and use it to create a weekly project report.
Scenario: Customer Portal Enhancement Project
Your team is working on a customer portal enhancement project. The goal of the project is to improve the customer self-service experience by adding new profile management, invoice download, and support ticket tracking features.
During the current week, the team completed development for three user stories. Functional testing started for two completed user stories. One user story is blocked because API confirmation is pending from the integration team. Regression testing is planned for next week, but required test data is not yet available. One medium-severity defect was found in the invoice download feature. The project manager has asked you to prepare a weekly project report for stakeholders.
The client is expecting a status update on whether the project is still on track for release readiness. Internal leadership also wants to know whether any escalation or support is required.
Raw Project Notes
Use the following raw notes to prepare the weekly project report.
| Area | Raw Notes |
|---|---|
| Project Name | Customer Portal Enhancement |
| Current Week | Week 3 |
| Development | Three user stories development complete. |
| Testing | Functional testing started for two user stories. |
| Blocked Work | One user story blocked due to pending API confirmation from integration team. |
| Risk | Regression testing may be delayed because test data is not ready. |
| Issue | One medium defect found in invoice download feature. |
| Next Week | Continue functional testing, start regression testing, close medium defect, confirm API dependency. |
| Support Needed | Support may be needed if API confirmation and test data are not received by agreed timeline. |
Weekly Project Report Template
Learners should use the following template to prepare the report.
| Report Section | Details to Fill |
|---|---|
| Project Name | |
| Reporting Period | |
| Prepared By | |
| Overall Status | Green / Amber / Red with explanation. |
| Executive Summary | Short 2-3 sentence summary of current project health. |
| Key Accomplishments This Week | Completed work and meaningful progress. |
| Work in Progress | Current active work. |
| Planned Work for Next Week | Activities planned for the next reporting period. |
| Risks and Issues | Important risks, issues, impact, owner, and action plan. |
| Dependencies and Blockers | Pending inputs, blocked work, and required support. |
| Decisions or Support Needed | Client or leadership decision/support required. |
| Action Items and Next Steps | Action, owner, due date, and status. |
Part 1: Decide the Overall Status
Based on the scenario, learners should decide whether the project status is Green, Amber, or Red. The status should not be selected randomly. It should be supported by facts.
| Status Option | When to Use | Would It Fit This Scenario? |
|---|---|---|
| Green | Project is on track with no major risk or issue. | No. There are dependencies and testing risks. |
| Amber | Project has risk or issue, but recovery is possible with action. | Yes. API dependency and test data risk may affect testing, but action can still recover the timeline. |
| Red | Project is blocked or seriously impacted and requires immediate intervention. | Not yet. The project is at risk, but not confirmed as unrecoverable. |
Suggested Status
The suggested status is Amber because one story is blocked, regression testing has a test data risk, and one medium defect is open. However, the project may still recover if dependencies are resolved on time.
Part 2: Draft the Executive Summary
The executive summary should give a quick view of the project status and the most important message.
Weak Executive Summary
“Project is going on. Some work is done and some testing is pending.”
Improved Executive Summary
“Project status is Amber. Development is complete for three user stories, and functional testing has started for two. One story is blocked due to pending API confirmation, and regression testing may be delayed if test data is not available by next week. The team is following up on dependencies and will provide an updated impact assessment after confirmation.”
This improved summary is better because it includes status, progress, risk, blocker, action, and next update.
Part 3: Write Key Accomplishments
Accomplishments should describe what was actually completed or meaningfully progressed during the week. They should not be vague activity statements.
| Weak Accomplishment | Strong Accomplishment |
|---|---|
| “Worked on user stories.” | “Completed development for three user stories.” |
| “Testing started.” | “Started functional testing for two completed user stories.” |
| “Defect review done.” | “Identified one medium-severity defect in invoice download feature and started review.” |
Suggested Accomplishments
- Completed development for three customer portal user stories.
- Started functional testing for two completed user stories.
- Identified one medium-severity defect in the invoice download feature and initiated defect review.
- Confirmed key activities required for next week’s regression testing preparation.
Part 4: Write Planned Work for Next Week
Planned work should describe the next reporting period’s expected activities. It should be realistic and connected to the current project status.
Suggested Planned Work
- Continue functional testing for completed user stories.
- Start regression testing if required test data is available.
- Resolve and retest the medium defect in the invoice download feature.
- Obtain API confirmation from the integration team for the blocked story.
- Prepare updated release readiness view based on testing and dependency status.
Part 5: Identify Risks and Issues
Learners should separate risks from issues. A risk may happen in the future. An issue is already happening and affecting the project.
| Item | Risk or Issue? | Reason | Suggested Report Statement |
|---|---|---|---|
| Test data is not ready for regression testing. | Risk | Regression testing is planned for next week and may be delayed if data is not ready. | “Regression testing may be delayed if required test data is not available before next week’s testing start.” |
| One medium defect found in invoice download feature. | Issue | The defect already exists and needs resolution. | “One medium-severity defect is open in the invoice download feature and is under review.” |
| API confirmation is pending from integration team. | Blocker / Dependency | One user story cannot proceed without API confirmation. | “One user story is blocked due to pending API confirmation from the integration team.” |
Part 6: Complete the Weekly Project Report
Based on the scenario and activity steps, the completed weekly project report may look like this.
| Report Section | Completed Weekly Project Report |
|---|---|
| Project Name | Customer Portal Enhancement |
| Reporting Period | Week 3 |
| Prepared By | Team Lead |
| Overall Status | Amber due to one blocked story, pending test data for regression testing, and one open medium defect. |
| Executive Summary | Development is complete for three user stories, and functional testing has started for two. One user story is blocked due to pending API confirmation. Regression testing may be delayed if required test data is not available before the planned start. |
| Key Accomplishments This Week | Completed development for three user stories. Started functional testing for two completed stories. Identified one medium-severity defect in invoice download feature and initiated defect review. |
| Work in Progress | Functional testing is in progress. Defect analysis is in progress for the invoice download issue. Follow-up is ongoing for API confirmation and test data readiness. |
| Planned Work for Next Week | Continue functional testing. Start regression testing if test data is available. Resolve and retest the medium defect. Confirm API dependency and resume blocked story. |
| Risks and Issues | Risk: Regression testing may be delayed if test data is not available before next week. Issue: One medium-severity defect is open in the invoice download feature. |
| Dependencies and Blockers | One user story is blocked due to pending API confirmation from the integration team. Test data readiness is required before regression testing can begin. |
| Decisions or Support Needed | Support may be needed if API confirmation and test data readiness are not received by the agreed timeline. |
| Action Items and Next Steps | Follow up with integration team for API confirmation. Follow up with data owner for regression test data. Continue functional testing. Confirm defect fix and retesting plan. |
Part 7: Action Items Table
Every weekly project report should clearly show important action items. This helps stakeholders understand who owns what and when action is expected.
| Action Item | Owner | Due Date | Status | Comments |
|---|---|---|---|---|
| Confirm API details for blocked user story. | Integration Team | Before next testing cycle | Pending | Required to unblock one user story. |
| Prepare required test data for regression testing. | Data Owner / Data Team | Before regression testing start | At Risk | Delay may affect regression testing schedule. |
| Analyze and fix medium defect in invoice download feature. | Development Team | Next week | In Progress | Testing team will retest after fix deployment. |
| Continue functional testing for completed stories. | Testing Team | Next week | In Progress | Testing already started for two stories. |
Part 8: Client-Friendly Weekly Update
Learners should also practice converting the weekly report into a client-friendly update. The client-friendly version should be shorter, professional, and focused on status, impact, and next steps.
Suggested Client-Friendly Update
“Current project status is Amber. Development is complete for three user stories, and functional testing has started for two. One user story is blocked due to pending API confirmation, and regression testing may be delayed if required test data is not available before the planned start. One medium defect has been identified in the invoice download feature and is under review. The team is following up on the API and test data dependencies and will share an updated impact assessment in the next reporting cycle.”
This update is client-friendly because it is concise, transparent, and avoids unnecessary internal detail.
Part 9: Internal Leadership Update
Internal leadership may need a slightly different version that highlights support needed and escalation triggers.
Suggested Internal Leadership Update
“Project status is Amber. Development is complete for three user stories, and functional testing has started for two. One user story remains blocked due to pending API confirmation. Regression testing is at risk because test data is not yet ready. One medium defect is open in the invoice download feature and is under review. Leadership support may be needed if API confirmation or test data readiness is not received before the next testing cycle. The team is continuing follow-up with dependency owners and will provide revised impact status after confirmation.”
This update is suitable for internal leadership because it clearly explains risk, impact, and possible support needed.
Part 10: Common Mistakes to Avoid
| Mistake | Why It Is a Problem | Better Practice |
|---|---|---|
| Writing vague updates such as “work is going on” | Stakeholders cannot understand real progress. | Use specific completed work and current work details. |
| Reporting only accomplishments | Risks and issues may remain hidden. | Include risks, issues, blockers, and dependencies. |
| No overall status | Stakeholders cannot quickly understand project health. | Use Green, Amber, or Red with explanation. |
| No action owner | Follow-up may not happen. | Assign owner for every key action. |
| No timeline or due date | Urgency is unclear. | Include due date or next update timing. |
| Using blaming language | Creates defensiveness and weakens collaboration. | Use neutral, fact-based language. |
Part 11: Improve the Report Language
Rewrite the weak updates below into strong weekly report statements.
| Weak Statement | Improved Weekly Report Statement |
|---|---|
| “Testing is pending.” | “Regression testing is pending because required test data is not yet available.” |
| “API issue is there.” | “One user story is blocked due to pending API confirmation from the integration team.” |
| “Defect is open.” | “One medium-severity defect is open in the invoice download feature and is under review.” |
| “We may be late.” | “Regression testing may be delayed if test data is not available before the planned start.” |
| “Need support.” | “Support may be needed if API confirmation and test data readiness are not received by the agreed timeline.” |
Part 12: Learner Practice Template
Learners can use the blank template below to create their own weekly project report.
| Report Section | Learner Response |
|---|---|
| Project Name | |
| Reporting Period | |
| Overall Status | |
| Executive Summary | |
| Key Accomplishments This Week | |
| Work in Progress | |
| Planned Work for Next Week | |
| Risks and Issues | |
| Dependencies and Blockers | |
| Decisions or Support Needed | |
| Action Items and Next Steps |
Evaluation Criteria
Facilitators can use the following criteria to evaluate learner reports.
| Criteria | Excellent | Needs Improvement |
|---|---|---|
| Overall Status | Status is clearly stated with reason. | Status is missing or not explained. |
| Accomplishments | Completed work is specific and outcome-focused. | Accomplishments are vague or activity-based. |
| Risks and Issues | Risks and issues are clearly separated with impact. | Risks and issues are mixed or unclear. |
| Actions | Actions include owner and due date. | Actions do not include ownership or timeline. |
| Tone | Professional, neutral, and solution-focused. | Blaming, vague, or overly casual. |
| Stakeholder Usefulness | Report helps stakeholders understand and act. | Report shares information but does not guide action. |
Facilitator Notes
- Ask learners to first write the report individually.
- Then ask them to compare reports in pairs or small groups.
- Encourage learners to identify vague statements and rewrite them clearly.
- Ask learners to explain why they selected Green, Amber, or Red status.
- Remind learners to include risks, issues, blockers, and next actions.
- Encourage professional tone and reporting without blame.
- Ask learners to prepare both client-friendly and internal leadership versions.
- Close the activity by discussing how weekly reports improve transparency and accountability.
Weekly Project Report Checklist
| Checklist Question | Yes / No |
|---|---|
| Does the report clearly state the reporting period? | |
| Does it include overall project status? | |
| Does it explain why the status is Green, Amber, or Red? | |
| Does it list completed work from the week? | |
| Does it list planned work for next week? | |
| Does it identify risks and issues? | |
| Does it mention blockers or dependencies? | |
| Does it include action owners? | |
| Does it include due dates or next update timing? | |
| Is the language professional and clear? |
Self-Reflection Questions
- Did I clearly explain the overall project status?
- Did I include specific accomplishments instead of vague activity updates?
- Did I separate risks, issues, blockers, and dependencies?
- Did I explain impact clearly?
- Did I include owners and due dates for action items?
- Did I avoid blame and use professional language?
- Did I tailor the report for stakeholders?
- Did the report help stakeholders understand what action is needed?
- What part of my weekly report was strongest?
- What part of my weekly report should I improve next time?
Key Takeaways
- A weekly project report gives regular visibility into project progress and project health.
- A strong weekly report includes status, accomplishments, planned work, risks, issues, blockers, and next steps.
- Status should be explained, not just shown as Green, Amber, or Red.
- Accomplishments should be specific and outcome-focused.
- Risks and issues should include impact, owner, and action plan.
- Dependencies and blockers should be clearly visible.
- Action items should include owner and due date.
- The report should be useful for decision-making, not just documentation.
- Client-friendly updates should be concise and business-focused.
- Internal leadership updates should highlight impact, support needed, and escalation triggers.
Conclusion
Creating a weekly project report is a practical skill every team lead should develop. A good report helps stakeholders understand what happened during the week, what is planned next, what risks or issues need attention, and what actions are required.
This activity teaches learners how to move from raw project notes to a structured, stakeholder-ready project report. It also reinforces the importance of clarity, accountability, professional tone, and timely communication.
The most important lesson is this: a weekly project report is effective when it turns project information into clear visibility, ownership, and action.