Project Manager

Create a project kickoff document for the following project. This is the single source of truth that the entire team will reference.

Project: Migrate our company from on-premise email (Microsoft Exchange) to Google Workspace
Company: Malaysian manufacturing company, 180 employees across 3 locations (KL, Penang, Johor)
Timeline: Must be complete within 8 weeks (factory operations cannot be disrupted)
Budget: RM45,000 (includes licensing, migration tool, and 2 days of on-site support per location)
Stakeholders: IT Director (sponsor), HR Manager (employee comms), Factory Managers (3), CEO (final sign-off on go-live date)

Kickoff document must include:
1. Project objective (one sentence — what does "done" look like?)
2. Scope: what is included AND explicitly what is NOT included (prevent scope creep)
3. Milestones: 8-week timeline with specific deliverables per week
4. RACI matrix for key activities (use the stakeholders listed above)
5. Risk register: top 5 risks with mitigation plans (include "factory staff refuse to switch" — this is the real risk)
6. Communication plan: who gets what update, how often, through what channel
7. Success criteria: measurable outcomes that determine if the migration succeeded
8. Decision log template: for tracking all decisions made during the project

Constraint: This document must fit in 3 pages. If it is longer, nobody will read it.

Transform these raw project data points into a weekly status report that leadership actually reads. The current format is a bullet list nobody opens.

Project: E-commerce platform build for a Malaysian fashion retailer
Week 5 of 12

Raw data:
- Sprint velocity: 34 points completed (planned 40) — 85%
- Backend API: 70% complete (on track)
- Frontend UI: 55% complete (behind by 1 week — designer was on medical leave for 3 days)
- Payment gateway integration: Not started (blocked — waiting for Stripe MY approval, submitted 2 weeks ago)
- Client feedback session: Done — 12 change requests, 4 accepted, 8 deferred to Phase 2
- Bug count: 23 open (14 low, 7 medium, 2 critical)
- Budget burn: RM92K of RM200K spent (46%)
- Next milestone: User Acceptance Testing starts Week 8

Status report format:
1. One-line project health (green/yellow/red with a 10-word summary)
2. This week's story (3 sentences — what happened and why it matters)
3. Key metrics dashboard (table format, showing planned vs actual vs trend)
4. Blockers (ranked by impact, with owner and expected resolution date)
5. Decisions needed from leadership (be specific — "approve X by Friday" not "we need guidance")
6. Next week's focus (top 3 priorities)
7. Risk update: has anything changed in the risk profile?

Constraint: The full report must be readable in 2 minutes. Use colour coding (green/yellow/red) for at-a-glance scanning.

I am planning a large system migration and I need to identify risks I have not thought of. Play the role of a battle-scarred project manager who has seen migrations go wrong 50 times.

Project: Migrating 8 years of customer data from a legacy CRM (on-premise SQL Server) to HubSpot for a Malaysian insurance brokerage with 2,000 active clients.

Risks I have already identified:
1. Data loss during migration
2. Downtime during cutover
3. Staff resistance to new system
4. Budget overrun

Now identify 10 MORE risks I have missed. For each:
1. The risk (specific scenario, not generic)
2. Likelihood (1-5)
3. Impact (1-5)
4. Why I missed it (what cognitive bias made me overlook it)
5. Early warning signal (how would I detect this risk materialising?)
6. Mitigation plan (specific actions, not "have a contingency plan")

Focus on:
- Risks specific to CRM migrations (not generic project risks)
- Risks specific to insurance industry data (policy numbers, claim histories, compliance records)
- People risks (the ones that kill projects more often than technical risks)
- Post-migration risks (things that go wrong after you think you are done)

Constraint: At least 3 risks must be ones that would not appear on any standard risk register template.

Design meeting agendas for these 3 recurring meetings. The goal is to cut each meeting's duration by 40% while improving outcomes.

Meeting 1: Weekly Team Standup (currently 45 min, 8 people)
Problem: Turns into a status report that could be async. People zone out when others are talking.

Meeting 2: Bi-weekly Client Check-in (currently 60 min, 5 people — 3 internal, 2 client)
Problem: Client uses it to add scope. No clear actions come out of it.

Meeting 3: Monthly Project Review (currently 90 min, 12 people — includes leadership)
Problem: Too many people, first 30 minutes are context-setting that could be pre-read.

For each meeting, provide:
1. New target duration
2. Pre-meeting work (what participants must do BEFORE the meeting)
3. Agenda with timed sections (strict time boxes)
4. Facilitator notes (how to keep it on track)
5. Decision/action capture format
6. "Meeting cancelled if..." rule (when this meeting should not happen)
7. Async alternative: what could replace this meeting entirely if we were brave enough

Constraints:
- Standup should be under 15 minutes
- Client check-in should have a written agenda sent 24 hours before with a "scope change" parking lot
- Project review should have a pre-read with the rule: "if you have not read the pre-read, you do not attend"

A client just requested a scope change mid-project. Help me assess the impact and prepare a response.

Original scope: Build a customer portal with login, dashboard, and support ticket submission. Timeline: 10 weeks, budget RM80K.

We are in Week 6. Current status: Login and dashboard complete. Support ticket module is 60% done.

Client request: "We also need a live chat feature integrated with the portal. Our CEO saw a competitor has it and wants it before launch."

Assess:
1. Impact on timeline (be specific — how many additional weeks?)
2. Impact on budget (estimate in RM, not percentages)
3. Impact on quality of existing features (will rushing this compromise what is already built?)
4. Impact on team morale (they just got the hang of the sprint rhythm)
5. Technical dependencies (does live chat affect the architecture of what is already built?)

Then prepare:
6. Three response options:
   a. Accept and extend timeline + budget
   b. Accept but swap out another feature (what would you cut?)
   c. Defer to Phase 2 with a compelling reason
7. A one-page change request document with the recommended option
8. Talk track for the call with the client (how to say "yes, but here is what it costs" without damaging the relationship)

Context: This is our biggest client (40% of revenue). We cannot say a flat "no".

I manage 4 concurrent projects with a shared team of 8 people. Help me optimise resource allocation for the next 4 weeks.

Team:
1. Rina — Senior developer, strongest on backend, also does code reviews (available 40h/week)
2. Hafiz — Mid developer, frontend specialist (available 40h/week)
3. Mei — Junior developer, learning fast, needs code review on all PRs (available 40h/week)
4. Aiman — Full-stack, reliable but slow, very thorough (available 40h/week)
5. Syahirah — Designer, also does user research (available 32h/week — Fridays off)
6. Faisal — QA engineer, also writes automated tests (available 40h/week)
7. Nadia — Project coordinator, handles client comms and scheduling (available 40h/week)
8. Zul — DevOps, handles deployments and infrastructure (available 20h/week — shared with another department)

Projects and needs:
Project A (Priority 1, deadline Week 4): Backend API completion — needs 80h backend + 20h QA
Project B (Priority 2, deadline Week 3): UI redesign — needs 60h frontend + 40h design + 15h QA
Project C (Priority 3, deadline Week 6): New feature build — needs 40h full-stack + 20h design + 10h QA
Project D (Priority 4, ongoing): Bug fixes and maintenance — needs 20h/week across all skills

Create:
1. Person-by-project allocation table (hours per week for 4 weeks)
2. Conflicts and trade-offs (where the math does not work)
3. Risk: single points of failure (if person X is sick, project Y stops)
4. My recommendation: what to do about Project D (starve it, or protect minimum hours?)
5. One creative solution I probably have not considered (cross-training, pair programming, deferring non-critical tasks)
6. The conversation I need to have with leadership about what is realistic

Design a sprint retrospective for my team that avoids the usual "what went well, what did not" format. The team is bored of retros and thinks they are a waste of time.

Team context: 7 people, been working together for 6 months, recently completed a tough 3-month project with a difficult client. Morale is mixed — some proud, some burned out. One team member privately told me they are thinking of leaving.

Design a retro that:
1. Takes exactly 45 minutes (not a minute more)
2. Uses a creative format (not sticky notes on a board)
3. Gets the quiet people to speak (2 of my 7 are introverts who never contribute in retros)
4. Addresses the burnout elephant in the room without making it awkward
5. Produces exactly 3 action items with owners and due dates (not 15 items nobody follows up on)

Provide:
- Minute-by-minute facilitator script
- Materials needed (physical or digital)
- Warm-up activity (2 minutes, breaks the ice)
- Core activity with specific instructions
- How to handle if someone gets emotional or vents excessively
- Closing ritual that creates a sense of completion

Constraint: The retro must feel different from every retro they have done before. If it feels like the same format with a new name, it will fail.

Write a comprehensive post-mortem for a completed project. Be honest about what went wrong — this is an internal learning document, not a client deliverable.

Project: Built and launched an internal employee portal for a Malaysian bank (350 users)
Planned: 12 weeks, RM150K, team of 5
Actual: 18 weeks, RM210K, team of 7 (added 2 contractors mid-project)

Key events:
- Week 3: Client changed authentication requirement from SSO to multi-factor (2-week impact)
- Week 6: Lead developer went on extended medical leave, replaced by contractor who needed 2 weeks to ramp up
- Week 9: Security audit failed — 14 findings, 3 critical, required 3 weeks of remediation
- Week 12: UAT revealed performance issues under load — portal crashed with 200 concurrent users, target was 350
- Week 15: Performance issues fixed, security remediation complete, UAT passed
- Week 18: Launched successfully, 95% adoption in first 2 weeks

Client satisfaction: "Happy with the result, disappointed with the timeline and communication during the delays."

Post-mortem structure:
1. Project health scorecard (scope, time, cost, quality, satisfaction — each rated red/yellow/green)
2. Root cause analysis: Why did each overrun happen? (Go deeper than "scope change")
3. What would we do differently if we started this project tomorrow?
4. Process improvements: 5 specific changes to our project delivery methodology
5. Estimation accuracy: analyse where our estimates were wrong and by how much
6. Team feedback highlights (anonymised)
7. Client relationship assessment: how to restore trust for the next project
8. The single biggest lesson from this project (one paragraph)