Skills

Complete a Pro Bono Consulting Engagement

12 weeks · 0 milestones

Deliver a real consulting engagement to a real client — either pro bono or as a simulation with a real organisation as the subject — producing a substantive deliverable (strategy document, market analysis, operational diagnostic, financial model) and receiving formal sign-off from the client or engagement supervisor on its quality. The engagement must involve genuine back-and-forth with the client: at least one instance where the client's reality diverged from initial assumptions and the deliverable was revised in response. Proof is the deliverable, the client sign-off, and a reflection documenting the specific revision and what the engagement revealed about the gap between desk analysis and organisational reality.

Part of: Business · Proves for: UG

Milestone map

3 milestones

Scope a real engagement in writing

1–2 weeks

Find a real client, such as a nonprofit or small business. Agree the problem, scope and deliverable in writing. A written scope protects both sides and defines done.

Proof required

Submit the signed or emailed scope agreement: problem, deliverable, timeline and client contact, with confidential details redacted.

What gets checked

A real client organisation
Deliverable and timeline agreed in writing
Client contact named

Common mistakes

An invented client
Scope agreed only verbally
A problem too big for the time

Powstik Guide

A written scope with a real client.

Steps

Find a client through a pro bono network or contacts.
Ask what decision they need help with.
Narrow it to one deliverable.
Put scope, timeline and contact in writing.

Template

Scope of work
Client:
Problem:
Deliverable:
Out of scope:
Timeline:
Client contact:
Agreed on (date):

What gets sent back

An invented client.
Verbal-only scope.
No deliverable defined.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Confirm the client exists
Check the written agreement
Check scope fits the timeline

You'll sign in first, then come straight back here.

Research, analyse and draft recommendations

4–6 weeks

Gather evidence from interviews and data. Structure the problem so nothing is missed or counted twice. Draft recommendations tied to the evidence.

Proof required

Submit your issue tree, research log (who you spoke to, what data you used) and the draft recommendations.

What gets checked

Issue tree with no gaps or overlaps
Evidence from real interviews or data
Each recommendation tied to evidence

Common mistakes

Recommendations before research
Only desk research
Unsupported claims

Powstik Guide

An issue tree, research log and draft recommendations.

Steps

Break the problem into non-overlapping parts.
Interview at least a few people close to it.
Gather the data each part needs.
Write each recommendation with its evidence.

Template

Issue tree
Main question:
├─ Part A
│  ├─ A1
│  └─ A2
└─ Part B

| Recommendation | Evidence | Source |
|----------------|----------|--------|

What gets sent back

No primary research.
Recommendations without evidence.
Overlapping issue tree parts.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Check the issue tree
Check the research log
Trace one recommendation to its evidence

You'll sign in first, then come straight back here.

Deliver and get client feedback

1–2 weeks

Present the final deliverable to the client, leading with the recommendation. Collect written feedback on its usefulness. Note what they decided to do.

Proof required

Submit the final deliverable (redacted as needed), written client feedback, and a note on what the client decided.

What gets checked

Delivered to the real client
Written feedback from the client
Client decision recorded

Common mistakes

Delivered but no feedback asked for
A deck with no clear recommendation
Confidential data shared

Powstik Guide

A delivered recommendation and written client feedback.

Steps

Put the recommendation on the first page.
Present live and take questions.
Ask for written feedback on usefulness.
Record what the client decided.

Template

Deliverable first page
Recommendation:
Why (three reasons):
What it will take:

Client feedback (quote):
Client decision:

What gets sent back

No client feedback.
No clear recommendation.
Unredacted confidential data.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Check the client feedback is from the client
Check the recommendation leads
Check redaction

You'll sign in first, then come straight back here.

Part of

Business Administration Electives: Consulting and leadership →

Related outcomes

Milestone map

3 milestones

Scope a real engagement in writing

1–2 weeks

Find a real client, such as a nonprofit or small business. Agree the problem, scope and deliverable in writing. A written scope protects both sides and defines done.

Proof required

Submit the signed or emailed scope agreement: problem, deliverable, timeline and client contact, with confidential details redacted.

What gets checked

A real client organisation
Deliverable and timeline agreed in writing
Client contact named

Common mistakes

An invented client
Scope agreed only verbally
A problem too big for the time

Powstik Guide

A written scope with a real client.

Steps

Find a client through a pro bono network or contacts.
Ask what decision they need help with.
Narrow it to one deliverable.
Put scope, timeline and contact in writing.

Template

Scope of work
Client:
Problem:
Deliverable:
Out of scope:
Timeline:
Client contact:
Agreed on (date):

What gets sent back

An invented client.
Verbal-only scope.
No deliverable defined.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Confirm the client exists
Check the written agreement
Check scope fits the timeline

You'll sign in first, then come straight back here.

Research, analyse and draft recommendations

4–6 weeks

Gather evidence from interviews and data. Structure the problem so nothing is missed or counted twice. Draft recommendations tied to the evidence.

Proof required

Submit your issue tree, research log (who you spoke to, what data you used) and the draft recommendations.

What gets checked

Issue tree with no gaps or overlaps
Evidence from real interviews or data
Each recommendation tied to evidence

Common mistakes

Recommendations before research
Only desk research
Unsupported claims

Powstik Guide

An issue tree, research log and draft recommendations.

Steps

Break the problem into non-overlapping parts.
Interview at least a few people close to it.
Gather the data each part needs.
Write each recommendation with its evidence.

Template

Issue tree
Main question:
├─ Part A
│  ├─ A1
│  └─ A2
└─ Part B

| Recommendation | Evidence | Source |
|----------------|----------|--------|

What gets sent back

No primary research.
Recommendations without evidence.
Overlapping issue tree parts.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Check the issue tree
Check the research log
Trace one recommendation to its evidence

You'll sign in first, then come straight back here.

Deliver and get client feedback

1–2 weeks

Present the final deliverable to the client, leading with the recommendation. Collect written feedback on its usefulness. Note what they decided to do.

Proof required

Submit the final deliverable (redacted as needed), written client feedback, and a note on what the client decided.

What gets checked

Delivered to the real client
Written feedback from the client
Client decision recorded

Common mistakes

Delivered but no feedback asked for
A deck with no clear recommendation
Confidential data shared

Powstik Guide

A delivered recommendation and written client feedback.

Steps

Put the recommendation on the first page.
Present live and take questions.
Ask for written feedback on usefulness.
Record what the client decided.

Template

Deliverable first page
Recommendation:
Why (three reasons):
What it will take:

Client feedback (quote):
Client decision:

What gets sent back

No client feedback.
No clear recommendation.
Unredacted confidential data.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Check the client feedback is from the client
Check the recommendation leads
Check redaction

You'll sign in first, then come straight back here.