Salesforce Project Coordination Intern

Choose a Salesforce implementation to plan and run yourself: a CRM for a business you understand, scoped to something genuinely achievable.

Write the project charter.

State the business problem, the objective, what is in scope, what is explicitly out of scope, who the stakeholders are, what success looks like measurably, and the constraints.

The out-of-scope list is the most useful line in the document, since every project is attacked through its ambiguity.

Break the work down.

Decompose the project into deliverables, then into tasks small enough to estimate, each with an owner and an effort estimate.

State your estimating assumptions.

Now sequence it.

Identify which tasks depend on which, and find the critical path, the sequence where any delay delays the whole project.

Mark it clearly, because effort spent accelerating off-path work buys nothing.

Build the schedule with milestones, defining each as a verifiable state rather than an activity, such as data model approved rather than work on data model.

Plan the checkpoints.

Decide when you will review progress, what you will measure, and what would trigger replanning.

Then stress the plan.

Write what happens if the single longest task takes twice as long, and what you would cut first if time ran short.

A plan with no stated sacrifice order gets cut arbitrarily under pressure.

Finally, record your confidence per milestone and which you are least sure about.

Submit the charter with scope exclusions, the work breakdown with estimates and assumptions, the dependency map with critical path, the milestone schedule, the checkpoint plan, the stress analysis with cut order, and the confidence assessment.

Projects fail on risks identified late or logged and then ignored.

Build the risk register.

Identify at least twelve risks across categories: technical, data, people and adoption, scope, and dependency on others.

For each, record what could happen, how likely, how bad, who owns it, and what you would do to reduce the chance or the impact.

Distinguish prevention from response, since they are different actions.

Prioritise properly.

Rank the risks by likelihood and impact together, and identify the three that would most damage the project.

For your top three, write a contingency plan, stating the trigger that would tell you the risk is materialising.

A risk without a trigger is noticed too late.

Now run the project.

Sign up for a free Developer Edition org and begin building according to your plan, tracking actual effort per task against your estimate.

Log what actually happens.

Maintain an issue log of problems as they arise, distinguishing an issue, which is happening now, from a risk, which might.

For each issue, record the impact, what you did, and whether it was on your risk register, since the ones that were not are the most instructive.

Track the estimate variance.

Where actual effort differed from estimate, record by how much and why, and write what that teaches about your estimating.

Then update the register.

Close risks that passed, add ones you did not foresee, and reassess the rest.

Finally, write the risk you underestimated most and what you missed.

Submit the risk register with prevention and response, the prioritisation, the top three contingencies with triggers, the build progress with effort tracking, the issue log, the variance analysis, the updated register, and the underestimated risk note.

UAT is where a project discovers whether it built the right thing, as distinct from whether it built the thing correctly.

Complete enough of your build to be testable, and populate it with realistic data.

Plan the UAT.

State what is being tested and what is not, who the testers are and what role each represents, the entry criteria before testing begins, and the exit criteria that mean testing is complete.

Without exit criteria, UAT ends when people get tired rather than when the system is ready.

Write the test scenarios as business tasks rather than system steps, describing what the user must achieve and leaving them to work out how, since that is what reveals whether the system makes sense.

Prepare the testers.

Write the brief they receive, including how to log a problem, and set the expectation that finding problems is the purpose.

Run it with at least three people.

Have each work through the scenarios without your help, observing where they struggle.

Manage what comes back.

Log every item, then classify each as a defect where the system does not work as intended, a usability problem where it works but confuses, a missed requirement where it was never specified, or a new request.

This classification decides what gets fixed now, since treating new requests as defects is how UAT becomes endless.

Triage by severity, fix what must be fixed, and retest with a tester.

Then decide.

Write the go or no-go recommendation against your exit criteria, with what remains outstanding.

Finally, write what UAT revealed that your own testing never would have.

Submit the UAT plan with exit criteria, the business scenarios, the tester brief, observation logs, the classified feedback, the triage and fixes with retest, the go or no-go decision, and the UAT insight.

Scope creep kills projects quietly, and closure is where the next project's improvement is won or lost.

Handle the change requests.

Write five requests arriving mid-project, phrased as stakeholders really phrase them, including one from the sponsor that is genuinely important and one that is reasonable but would break the timeline.

Assess each properly.

For every request, document the impact on scope, effort, timeline, and risk, then decide to accept it now, defer it, or decline it, with the reasoning.

Write the response you would give the requester, which must preserve the relationship while protecting the project.

Implement what you accepted, and record the actual impact against your assessment.

Handle the hard one.

For the sponsor's important request that does not fit, write the conversation you would have, including what you would propose giving up to accommodate it.

Saying yes without a trade is how projects fail.

Now close the project.

Write the completion report covering what was delivered against the original scope, what was descoped and why, actual effort against estimate with the variance explained, what slipped and the consequence, and the status of outstanding items.

State the uncomfortable facts plainly, since a closure report hiding them is worthless.

Assess the benefit.

Report against the measurable success criteria from your charter, including anything not achieved.

Write the lessons learned.

Produce at least six, each stating what happened, what you learned, and what you would do differently, covering both what went wrong and what went right for identifiable reasons.

Then hand over.

Write what the ongoing owner needs: outstanding items, known limitations, and who to contact.

Finally, write the one decision you would reverse.

Submit the five change requests with assessments and responses, the implemented change with actual impact, the sponsor conversation, the completion report, the benefit assessment, the lessons learned, the handover, and the reversed decision.