How to Accurately Diagnose Projects Without Matt
INTRODUCTION
Your job as a project leader/PM/Problem solver is not to manage tasks.
Your job is to prevent disasters before they occur.
A diagnostic is the tool that lets you:
- Predict problems
- Prevent scope creep
- Protect timelines
- Keep clients accountable
- Reduce surprise complexity
- Ensure correct staffing
- Give the team clarity
- Avoid dragging Matt into avoidable chaos
If you get the diagnostic right, the project runs clean.
If you get it wrong, everything downstream becomes firefighting.
This guide teaches you how to think like a strategist—not just a coordinator.
SECTION 1 — THE MINDSET OF A GREAT DIAGNOSTIC
1. Always Assume the Client’s Description Is Wrong
Clients describe symptoms, not problems.
Examples:
- “We need a redesign” → No, their messaging is weak.
- “We need SEO help” → No, they lack content discipline.
- “We want a better checkout” → No, fulfillment is broken.
Your job is to uncover the real issue.
Rule:
If the client’s problem sounds too clean or too simple, you’re missing something.
2. Look for What’s Missing, Not What’s Present
Anyone can write down what the client said.
A PM earns their value by noticing what wasn’t said.
Examples:
- No decision maker identified
- No clarity on content responsibilities
- No awareness of technical dependencies
- No discussion of risks
- No post-launch KPIs
Missing information is where 90% of risk hides.
3. Never Start Work When Unknowns Are High
Unknowns are the enemy of predictable delivery.
If you start prematurely:
- timelines stretch
- budgets blow
- Matt gets pulled in
- clients get frustrated
- quality drops
Your job is to reduce unknowns before production—via clarification, research, pre-sprints, or discovery.
4. Default to Red Until Proven Otherwise
This forces discipline.
Green = simple
Yellow = manageable
Red = unknowns, complexity, risk
If you assume Green, you’ll miss landmines.
If you assume Red, you’ll catch them early.
SECTION 2 — HOW TO THINK ABOUT COMPLEXITY
There are only three kinds of complexity you will ever face:
1. Technical Complexity
Signs:
- Custom development
- Multiple APIs
- Conditional workflows
- Ecommerce logic
- Data migration
- Automations
When you see these, don’t guess.
Get a technical lead involved early.
Matt gets involved only if:
- There are unknown APIs
- The systems involve business logic
- The architecture affects long-term scaling
2. Organizational Complexity
Signs:
- Many stakeholders
- No decision authority
- Clients who change direction
- Internal politics
- Subjective approval processes
These projects fail because of humans, not technology.
Rule:
If a project has more than 2 stakeholders, expect friction.
Your diagnostic should identify where decisions will bottleneck.
3. Content Complexity
This is the #1 timeline killer.
Signs:
- Client has no content
- Client “will write it”
- Content is distributed across teams
- They don’t know their messaging
- They don’t know their customer
Rule:
If content isn’t 80% ready before kickoff, assume delays.
Content sprints exist to solve this.
SECTION 3 — HOW TO IDENTIFY RISKS ACCURATELY
Every project has risks.
Your diagnostic must find them before they bite.
There are four major types:
1. Known Risks (visible upfront)
Examples:
- Third-party reliance
- Missing content
- Budget limitation
- Tight timelines
These must be written clearly.
2. Hidden Risks (not said, but inferred)
Examples:
- Client says “We need it fast” but has 6 decision-makers
- Client says “We have content” but can’t show it
- Client says “We’re tech savvy” but use outdated systems
Hidden risks are found by reading between the lines.
3. Behavioral Risks
Examples:
- Client ignores instructions
- Slow feedback loops
- Constant revisions
- Emotional decision making
These are the hardest risks.
Use the client’s past behavior to predict future behavior.
4. Structural Risks
Examples:
- Incomplete architecture
- Unclear dependencies
- Unvalidated assumptions
- Unstable hosting
You must identify these before quoting timeline or price.
SECTION 4 — HOW TO RUN A DIAGNOSTIC INTERVIEW
Ask these categories of questions:
1. Business Outcome Questions
Goal: find the real result.
Questions:
- What do you want this to accomplish for the business?
- What would make this project a failure?
- What must be true 90 days after launch?
2. Requirements Questions
Goal: clarify deliverables.
- What pages?
- What features?
- Any custom workflows?
- Any external systems?
3. Constraints Questions
Goal: identify where things will break.
- Budget
- Timeline
- Internal resources
- Access limitations
4. Stakeholder Questions
Goal: find the decision makers.
- Who approves final work?
- Who provides content?
- Who signs off milestones?
If unclear → red flag.
5. Risk Questions
Goal: expose weaknesses.
- What concerns you about this project?
- Where have past projects gone wrong?
- What are you uncertain about?
Clients will reveal their fears—listen carefully.
SECTION 5 — HOW TO SCORE A PROJECT CORRECTLY
Use R/Y/G scoring.
Here’s how to think about each:
Green (0–3)
- Clear scope
- 1–2 stakeholders
- No integrations
- Content is ready
- Budget + timeline aligned
These can run without Matt.
Yellow (4–8)
- Some unknowns
- Some unclear requirements
- 1–2 integrations
- Several stakeholders
- Content incomplete
- Tight but possible timeline
Matt reviews diagnostic, but not involved in build.
Red (9+)
- Unclear scope
- Unknown integrations
- Custom logic
- Missing content
- No clear decision authority
- Conflicting priorities
Matt must be strategically involved early.
SECTION 6 — HOW TO WRITE A DIAGNOSTIC SUMMARY LIKE A STRATEGIST
The summary must be:
- short
- factual
- specific
- non-emotional
- useful
Write for a busy executive, not for yourself.
Use this format:
- Business objective
- Scope (high level)
- Critical path
- Risks & unknowns
- Dependencies
- Complexity rating (RYG)
- What must happen before kickoff
- What requires Matt, if anything
If your summary is over one page, you misunderstood the project.
SECTION 7 — THE 10 PM HABITS OF A WORLD-CLASS DIAGNOSTIC
- Default to red until proven otherwise
- Solve unknowns before assigning tasks
- Never trust “the client will provide content”
- Push for clarity when things feel vague
- Ask questions until there are no surprises left
- Identify assumptions and validate them
- Protect the team from unclear requirements
- Close gaps instead of documenting them
- Think strategically, not administratively
- Your job is not to be agreeable—your job is to be accurate
SECTION 8 — WHAT TO ESCALATE TO MATT (AND WHY)
Escalate these every time:
- unknown APIs
- architecture decisions
- multi-system dependencies
- business logic that affects revenue
- long-term infrastructural impact
- brand-level messaging/positioning
- high-risk ecommerce
- red projects
If it could affect profitability, operations, or business strategy—he needs to see it.
Everything else: the team can handle.
FINAL REMINDER:
A diagnostic is not paperwork.
It is risk prevention, scope alignment, and complexity classification.
When done well:
- Projects run cleanly
- Client expectations align
- Team stays focused
- Matt’s involvement is strategic, not reactive
- The agency scales without chaos
When done poorly, every problem in the project can be traced back to the diagnostic.