Running a project with SSLM

Getting started with SSLM

You know what a project manager does — now run one. This page turns the fundamentals into action: why SSLM, how each idea becomes a document you fill in, and a step-by-step path through your first project. New to the fundamentals? Start with New to Project Management.

Why SSLM Fundamentals → documents The Project Reference Your first project First-week checklist Where to go next SSLM mistakes to avoid

The case for it

Why start with SSLM

If you're new to project management, the framework you learn on matters. SSLM is a good place to start.

It's light. SSLM asks for the least process that does the job, so your first project isn't buried in paperwork. You add more only when a real trigger calls for it.

It's ready-made. You learn by using proven templates, not by inventing them — spend your energy learning to run the project, not designing forms.

It builds good habits by default. Honest status, logging RAID as you go, planning to the critical path, and being willing to stop are baked into how SSLM works.

It's methodology-agnostic. Learn it once and apply it under Waterfall, Agile or a hybrid — you won't relearn the fundamentals when the delivery style changes.

It scales with you. Start on a small project (Tier 1). The same tools carry up to programs and portfolios later, so your learning keeps its value.

It keeps you honest about value. Strategy is the gate and benefits are the proof — you learn to connect a project to why it exists, not just to finish it.

Heavier, certification-first methods can overwhelm a first-timer. SSLM gives you the part that delivers most of the value, with a clear path to more depth as you grow — and it coexists with PRINCE2, PMBOK or SAFe rather than replacing them.

From idea to document

How each fundamental becomes something you fill in

SSLM gives you a ready-made set of documents and a governance rhythm, so you don't have to invent any of the fundamentals. Here's how each PM need becomes a template.

The PM need	The SSLM tool	Where to go deeper
Justify and start a project	PTIP, Business Case	PTIP Prioritisation; Change Request & Idea Intake
Plan to the critical path	Project Plan & Schedule	the SOP, section 3
Manage risks and issues	RAID and Tracker Logs	RAID Log & Escalation
Govern and decide	SteerCo, Terms of Reference, Minutes	Meeting Playbook
Report status	Weekly / Monthly / Board reports	Status Reporting
Control change	Change Request	Change Request & Idea Intake
Engage stakeholders	Stakeholder & Comms Plan, RACI	Stakeholder Management, RACI & Communication
Assure quality of delivery	Health-Check, Risk & Assurance tools	Risk & Assurance Approach
Track money and vendors	Cost & Resource Plan, Vendor Register	Budget, Cost & Resource; Vendor & Procurement
Prove the value	Benefit Register	Benefits Realisation & Post Go-Live Tracking
Close and learn	Closure & Handover Report	Lessons Learned & Closure Facilitation
Choose a simple solution	Design Principles Register	Design Principles

The one thread

The Project Reference

Every document carries one number. From the moment an initiative is prioritised through to closure, every SSLM document carries a single Project Reference (format YYYY-NNN, e.g. 2026-001). That one number turns a dozen separate documents into one connected story — proposed, approved, changed, decided, delivered. It is the thread that makes an SSLM project auditable and easy for someone else to pick up. If a document doesn't carry the reference, it has drifted out of the story.

Step by step

Running your first project

The whole shape of an SSLM project, from green light to closure.

It's prioritised on the PTIP and given its reference; a Business Case is approved at Green Light.
You set up your folder, copy the templates, and start the Project Plan and the RAID log.
You build your stakeholder map and RACI, book your SteerCo and team meetings, and send your first Weekly Update.
Through delivery you keep the plan, RAID and reporting current; a Change Request handles any baseline change.
Benefits are baselined in the Business Case at the start; before go-live you confirm the benefit baseline; at closure you review the benefit position, consolidate the Lessons Learned log (kept throughout), and complete the Closure & Handover Report.

Your first week — a checklist

The shortest path from “I've been asked to run this project” to a working set of documents. Tick these off — progress is tracked below.

Day-one checklist

✓Confirm your Project Reference (YYYY-NNN) and an approved Business Case exist
✓Declare the complexity appetite (Low / High) at Green Light
✓Open the Project Plan & Schedule and set the milestone spine
✓Start the RAID & Tracker Logs — empty is fine, just start it
✓Set the governance rhythm: weekly update + SteerCo cadence
✓Map stakeholders and draft a one-page RACI

0 of 6 done

Are you ready to run it?

If you can answer yes to most of these, you're ready to start — the rest you'll learn by doing.

Can you explain, in a sentence each, what scope, time, cost and benefits mean for your project?
Do you know who your sponsor and business owner are, and what each is accountable for?
Could you name your project's top three risks today?
Do you know which milestone is on the critical path?
Have you set up the plan and the RAID log, even lightly?
Do you know when your first weekly update and first SteerCo are?
Do you know which guide to open when a question gets deeper?

Where to go next

Which guide answers your question

Your question	The guide
How do I start in my first week?	Quick-Start Guide
How do I run SSLM with Waterfall, Agile or a value stream?	Delivery Methodologies Guide
How do I name files and number my log items?	Document Naming & Numbering Conventions Guide
How should I structure my project folder?	Version Control & Storage Guide
How do I run an effective meeting?	Meeting Playbook Guide
How do I map stakeholders and plan communications?	Stakeholder Management, RACI & Communication Guide
How do I manage risk, and when does an issue escalate?	Risk & Assurance Approach; RAID Log & Escalation
How do I write my reports?	Status Reporting Guide
How does an idea or change get approved?	Change Request & Idea Intake Guide
How are initiatives prioritised?	PTIP Prioritisation Guide
How do I close and capture lessons?	Lessons Learned & Closure Facilitation Guide
How do I track whether benefits landed?	Benefits Realisation & Post Go-Live Tracking Guide
How do I manage the people side of change?	Change Management Approach (ADKAR) Guide
How simple / low-maintenance should the solution be?	Design Principles Guide

Browse all templates & guides →

Learning aids

SSLM mistakes to avoid

The traps specific to running SSLM. (For the general new-PM ones, see New to Project Management.)

Inventing your own templates. The standard pack is what lets someone else pick up your project later. Change the ask before you change the block.
Treating the weekly update as optional. A short “nothing new, on track” still matters; silence creates uncertainty. Keep the cadence.
Raising a Change Request for normal re-prioritising. Only a change to baselined scope, time, cost, benefits or a deliverable needs a CR — not everyday re-planning inside the baseline.
Losing the Project Reference thread. If a document doesn't carry the reference, it drifts out of the story. Stamp every artefact with it.

Jargon? Every term is defined in the glossary →. You'll learn most by doing — and SSLM is built to make the first time a safe one.

As you grow. Take a single project up to a program or portfolio on Scale, or step into the office with Running a PMO.