Simple Solution, Low Maintenance
Practical Project Management for PMs & PMOs
Practical Project Management for PMs & PMOs
Start your first project
Guidance, templates & governance in one place
Congratulations, you have been handed your first project. This page gives you the first practical steps, in order, each tied to the SSLM principle and the ready-made template behind it. New to the fundamentals? Start with New to Project Management.
The nine steps below work with any tools. If you would rather have them built in, the free SSLM Light app carries a whole project from Business Case to Closure in one place, populate once and it propagates and reconciles for you, with an optional AI assistant on your own key. It works offline and keeps your data on your device.
Before you plan anything, get three things straight: why the project exists (Anchor to purpose), who is accountable for what (Clear accountability), and the shortest honest path to done (Plan to the critical path). The nine practical steps below put those into action. Do them across your first fortnight, capture your assumptions as you go, and report the real colour from the start.
Each step names what to do, the SSLM principle behind it, a practical example, and the template you use.
The very first thing to get is your project’s identity. Every SSLM document, from the first idea through to closure, carries one Project Reference (format YYYY-NNN, for example 2026-001). Ask your PMO, or check the PTIP, for the reference assigned when the project was prioritised; if one does not exist yet, get one issued. That single number turns a dozen separate documents into one connected, auditable story that someone else could pick up. From here on, stamp it on everything: if a document does not carry the reference, it has drifted out of the story.
SSLM principleNarrative flow and roll-up. One reference threads every document into a single connected story.
In practiceFor the Customer Returns Portal project your reference might be 2026-014. It goes in the header of the Business Case, the Project Plan, the RAID log, every Weekly Update and every SteerCo Pack, so the whole project reads as one story. Without one, the same project drifts into several names across teams, a change approved in one meeting cannot be tied to the plan it was meant to change, and when someone later asks who approved what and when, the trail has gone cold.
The templateIssued from the PTIP or by your PMO; carried in the header of every template.
Do not touch a plan until you can state, on one page, what the project is for and what done looks like. If a brief or Business Case already exists, read it and confirm you understand it. If it does not, write an Idea on a Page: the problem, the outcome, who benefits, rough scope, rough time and cost. Your Project Reference (from step 1) goes on it, so the whole story stays traceable from start to finish.
SSLM principleAnchor to purpose. Serve the project’s purpose over activity for its own sake.
In practiceFor a new Customer Returns Portal project, your one line might read: “Deliver an online returns portal so customers can lodge a return without phoning the contact centre. Done means the portal is live, staff are trained, and returns call volume has fallen.” That single sentence will settle a hundred later arguments about scope.
The templateIdea on a Page, then a light Business Case.
SSLM’s rule is one accountable owner per thing. Your first real conversation should be with the Sponsor: the person who is accountable, funds the work, and will chair your Steering Committee. Confirm the mandate, confirm your own authority and spending limits, and agree how they want to be kept informed, including their preferred style of communication and how much access to them you will have. Agree the reporting rhythm now, so the Weekly Update has a home from day one. From this first meeting, start a Decision Log and record every significant decision, who made it and when, from here on.
SSLM principleClear accountability. One accountable owner per decision, per deliverable, per risk.
In practiceAsk your Sponsor directly: “What can I decide on my own, and what must come to you or the Steering Committee first?” Getting that boundary in writing early stops you from either stalling on small calls or overstepping on big ones. Log that answer as your first entry in the Decision Log.
The templateThe roles are set out in the Terms of Reference and the SteerCo Pack. Record agreements and decisions in the Decision Log (a tab in the RAID & Tracker Logs).
A project delivers a benefit that someone in the business will own after go-live. Name that Business Owner early, because they define what good looks like and they accept the outcome at handover. Then map the key people the work depends on: those who must provide information, make decisions or do the work, inside and outside your team. You do not need a full stakeholder plan on day one, just a clear who’s who and who depends on whom.
SSLM principleClear accountability. Every outcome has one owner, and every dependency has a name against it.
In practiceFor the Returns Portal project, the Business Owner is the head of customer service, who will live with the portal after go-live. The key dependencies might be the IT team who host it and the contact-centre lead whose staff you will train. Name each one now, so a silent gap does not surface late.
The templateCapture the roles in the Terms of Reference. If the stakeholder map grows, add a RACI or a Stakeholder & Comms Plan on a trigger, not before.
Resist the urge to build a giant task list. Lay out the handful of milestones from today to done, in the order they must happen, and identify the critical path: the chain that, if it slips, slips the whole project. That is your Project Plan in its lightest form. A plan on a page is a great way to start presenting the project journey.
A good approach is to anchor the plan to one of the organisation’s strategic objectives. Call this Milestone Zero. From Milestone Zero, identify the five high-level milestones your project must deliver, these are your Level 1 milestones. Each is typically a dependency that must happen for the project to proceed, an obligation that must be met by a certain time (for example, to a regulator), or a significant, high-priority activity. Then, under each Level 1 milestone, name one lower-level milestone, deliverable or dependency that leads up to it, these are your Level 2 milestones. This is enough to get you started. You can change it freely before you baseline, and through change control once you have.
For example, if you are building a user interface on a CRM, the change management activities (communication, training, and any changes to people and the way they work) carry a higher priority than the colours, logos and images on the interface, but may be a lower priority than having the underlying technology in place in time. A clean, formatted data set ready for upload to the cloud might be a Level 2 milestone that leads up to the Level 1 milestone of delivering the CRM technology platform.
SSLM principlePlan to the critical path, and Fit for purpose. Plan the few things that drive the date, not every task, and keep the plan right-sized.
In practiceFor the Returns Portal project, the spine might be: approve Business Case, design the portal, build and integrate, test, train staff, go live, confirm benefits. The build cannot start before design is signed off, and go-live cannot happen before testing passes. That is your critical path.
The templateProject Plan & Schedule.
On a first project, it is common for people to be assigned to you from the PMO or from the department that owns the outcome, rather than chosen by you. Either way, get to know your team: whether each person is capable of the job they are assigned, and whether they have the bandwidth to commit fully or are still doing their day job and working on the project part-time. Where an external provider helps to deliver, be clear on where the division of labour cuts over: capture what they are committed to deliver and what you must provide from the client side, and vice versa.
SSLM principleCapable to deliver. Match the work to people who can do it, and know how much of them you actually have.
In practiceIf a developer is on the project but only two days a week, plan to two days, not five. If a vendor builds the portal, write down that they deliver the build while you provide the test data and the sign-off, so nothing falls in the gap between you.
The templateThe Project Plan & Schedule holds the resourcing. As the team and suppliers grow, a Cost & Resource Plan and a Vendor Register come in on a trigger.
Open a RAID log on day one: one place for Risks, Assumptions, Issues and Dependencies, and, in the same workbook, your decisions and actions. Its most valuable job at the start is your assumptions. You will have to assume things to get moving; the discipline is to write each assumption down with an owner and a date to confirm it. An unconfirmed assumption is a risk in waiting. When it is confirmed it becomes fact; when it is wrong, you caught it early. The most common assumptions to capture are set out just below.
SSLM principleReport the real colour, backed by evidence rather than opinion.
In practiceYou are told the test environment will be ready in week three. Log it as an assumption, owned by the IT lead, to confirm by the end of week two. If it slips, it is already visible and dated, not a surprise in week three.
The templateRAID & Tracker Logs.
Do not wait until you feel you have something impressive to report. Send a Weekly Update from your first week, even if it only says mobilising. It carries a RAG rating (red, amber or green) and a one-line trend of improved, stable or declined, and it is the base of the reporting chain that everything above rolls up from. The rule is simple: report the real colour. An amber that is honestly amber is worth far more than a green that is hiding a problem.
SSLM principleReport the real colour, and Narrative flow and roll-up. The weekly is the lowest level that everything above synthesises.
In practiceIn week one your update might be amber, because the team is not fully confirmed and the test environment is unproven. Saying so early sets an honest baseline and makes it normal to raise issues before they grow.
The templateWeekly Update.
Everything so far builds to your first gate: Green Light. That is the point where the Sponsor and Steering Committee approve the Business Case, which baselines the project and releases it into delivery. Pull your work into a right-sized Business Case: the purpose and outcome, the scope in and out, the milestone spine, the resources, and the main risks and assumptions. Add the baseline for any anticipated benefits; if something is targeted to improve or grow by 10 per cent, know the number that 10 per cent is growing from. Right-sized means the lightest case that lets a sensible person say yes; a first project rarely needs a heavy document.
SSLM principleRight-size governance, and Anchor to purpose. Enough case to make a sound decision, no more, and always tied to the purpose.
In practiceFor the Returns Portal project, the Business Case sets the cost to build against the saving in returns calls (capture the current number of returns calls as a baseline to measure the uplift from your project), the plan to go live, and the two or three risks that matter. Approving it at Green Light turns your draft plan into the baseline you deliver against.
The templateBusiness Case, presented at the Green Light gate (often in the SteerCo Pack).
A new PM’s biggest risk is the thing everyone “just assumed”. Assume what you must to get moving, but write every assumption in the RAID log with an owner and a date to confirm it. When it is confirmed it becomes fact; when it is wrong, you caught it early.
| What you are assuming | The assumption to make at the start | How to capture it |
|---|---|---|
| Scope | Nothing is in scope unless it is stated. | Write what is in and, just as important, what is explicitly out. |
| Definition of done | It is exactly as written until the Sponsor says otherwise. | Restate it on the Idea on a Page or Business Case and confirm at Green Light. |
| People | The named team are available at the level you were told. | Log each person and their percentage, and confirm with their manager. |
| Money and time | The budget and deadline are as stated in the brief. | Note whether the deadline is fixed or desired, and confirm both at Green Light. |
| Delivery method | You will use the method your organisation already uses. | Record it (Waterfall, Agile or Hybrid); do not introduce a new one. See Ways of delivering. |
| Dependencies | Other teams and projects will deliver on the date they gave. | Log each dependency with its owner and due date so it stays visible. |
Your first two weeks in one view, each step with the SSLM principle and template behind it.
| # | What you do | SSLM principle | SSLM template |
|---|---|---|---|
| 1 | Obtain your project reference number | Narrative flow and roll-up | Project Reference (PTIP / PMO) |
| 2 | Pin down the purpose | Anchor to purpose | Idea on a Page, Business Case |
| 3 | Meet the Sponsor, agree decisions | Clear accountability | Terms of Reference, SteerCo Pack, Decision Log |
| 4 | Name the Business Owner and key people | Clear accountability | Terms of Reference (RACI later) |
| 5 | Plan the milestone spine | Plan to the critical path, Fit for purpose | Project Plan & Schedule |
| 6 | Know your team and resources | Capable to deliver | Project Plan; Cost & Resource Plan, Vendor Register |
| 7 | Open the RAID log, capture assumptions | Report the real colour | RAID & Tracker Logs |
| 8 | Report weekly | Narrative flow and roll-up | Weekly Update |
| 9 | Reach the first gate | Right-size governance | Business Case at Green Light |
After the first two weeks, you should be feeling more comfortable in the role. You have begun building and refining the project plan, populating your RAID and Tracker logs, and getting to know the project stakeholders: the Sponsor, the Business Owner, and the teams you will work with, including your own project team. The next steps are to build up the processes and cadences of your project, form the governance around it, and settle into a steady rhythm of delivery.
From here, the project moves through the SSLM stages: Delivery, then Go-Live, then Post Go-Live, and finally Closure and Handover, where you pass the outcome to the Business Owner and capture what you learned for next time (Learn and improve). Each stage uses the same light core pack, growing only when the work genuinely demands it. You will not have everything perfect, and you are not meant to. Keep the purpose in front of you, keep one accountable owner on every decision, report the real colour, and let the standard SSLM blocks carry the structure. That is how a first project becomes a well-run one.
| 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 |
The traps specific to running SSLM. (For the general new-PM ones, see New to Project Management.)
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 (Project Management Office).