Implementation
Track, learn and adjust
During implementation, tracking should be simple and visible. Too many measures create fog. Too few create fantasy. A single-screen dashboard can help. Show key tasks, deadlines, issues, decisions, risks and next actions. For slightly larger projects, link the dashboard to a few objectives and key results. What are we trying to achieve, and how will we know whether implementation is actually working?
This matters because projects can look busy while drifting away from their purpose. Meetings happen. Updates are sent. Tasks move around. Everyone is exhausted. But are the benefits getting closer?
Implementation should track both activity and value. Not only “did we do the thing?” but “is the thing still producing the result we wanted?” Learning should also happen during delivery, not only after it. By the end, everyone is tired, the mistakes are historic, and the lessons learned document becomes a small museum of regret. Use short retrospectives during implementation. Ask: what should we start doing, stop doing and continue doing? What is slowing us down? What is working better than expected? What decision would make next week easier?
The point is not ritual. The point is adjustment. The sooner the team admits what is not working, the less expensive the lesson becomes.
Lead the people, not just the tasks
Implementation is a people problem pretending to be a task problem.
During delivery, leaders need to remove barriers, protect focus, manage energy and keep communication honest. This is especially important in charities and volunteer-heavy projects, where people may be motivated by purpose but still have limited time, capacity and patience.
Servant leadership is useful here: the project lead is not there to perform heroic control over every detail, but to help others do the work. What support do they need? What decision is blocking them? What information are they missing? What is making the task harder than it needs to be?
Emotional intelligence also matters. Delivery creates stress. People miss deadlines, get defensive, avoid bad news, or quietly disengage. A good implementation lead notices the temperature of the team before it becomes smoke.
Where the plan meets witnesses
Implementation is the point where a project stops being a document and starts becoming visible.
In planning, everything can still look controlled. The timeline fits. The budget behaves. The team seems available. The supplier is fictional but reliable. Then implementation begins, and the project meets people, delays, missing information, nervous stakeholders, tired volunteers, decision bottlenecks and reality’s usual lack of manners.
Implementation is not simply “doing the work.” It is the disciplined movement from intention to delivery. It means assigning tasks, managing resources, tracking progress, handling issues, communicating clearly, controlling changes and keeping the project alive long enough to produce the intended result.
For small businesses and charities, this phase is often where things unravel. Not because people do not care, but because caring is not a delivery system.
Move from plan to action
A plan only becomes useful when it turns into clear work.
Every task should have an owner, a deadline and a next action. Not a vague owner. Not “the team.” A person. Small organisations often rely on goodwill, which is admirable until nobody knows who was meant to call the supplier.
Implementation needs rhythm. Weekly check-ins, short progress updates, visible task boards and simple dashboards can do more than long dramatic meetings. The aim is to keep the work moving and make blockers visible early. What is done? What is stuck? What decision is needed? Who needs help? What changed since last week?
This does not need to be bureaucratic. It needs to be regular enough that the project cannot quietly disappear between everyone’s other responsibilities.
Watch for scope creep
Scope creep is what happens when the project keeps accepting extra work without properly changing the time, budget or resources.
It often arrives disguised as a small request. “Could we just add this?” “While we’re doing it, could we also fix that?” “It should only take a few minutes.” Famous last words. Many project disasters are built from small additions that each seemed too minor to challenge.
In a small business, this might be a website project where new features keep getting added until the launch slips by two months. In a charity, it might be an event that expands from a fundraiser into a full community festival without extra volunteers, budget or risk planning.
The answer is not to say no to every change. Some changes are sensible. But every change should be made visible. What does it add? What does it cost? What will it delay? Who approves it? What gets removed to make space?
If nothing changes in the plan after a change request, the plan is lying.
Manage issues before they become theatre
A risk is something that might happen. An issue is already happening.
Implementation needs an issue log because problems should not live only in someone’s head, inbox or emotional weather. Supplier delay. Volunteer dropout. Budget pressure. Missing approval. Technical failure. Stakeholder complaint. These should be recorded, owned and escalated when needed.
Escalation is not failure. It is how a project protects itself. A project manager should not sit on a serious issue because they want to look competent. Competence is knowing when a decision belongs above your pay grade, outside your authority, or beyond your available budget.
Small organisations often lose time here because nobody wants to bother the board, founder, manager or sponsor. So the team waits. The problem grows. Then everyone is surprised, which is apparently cheaper than governance until it is not.
Strategy is not planning
Strategy, planning, implementation and governance are related, but they are not the same thing.
Strategy chooses the direction. Planning works out the route, resources, timeline and responsibilities. Implementation does the work. Governance checks whether the work still makes sense, still has authority, and still deserves support.
Confusing these creates trouble. A detailed plan is not a strategy. A busy organisation is not necessarily a strategic one. A project delivered on time can still be the wrong project. That is the uncomfortable part people often avoid: good execution does not rescue a bad choice. It just delivers the mistake more efficiently.
Choose what not to do
A useful strategy creates focus. It says yes to some things and no to others. This is where many small organisations struggle, especially charities and mission-led businesses. When the cause matters, every opportunity can feel morally important. Every grant looks tempting. Every partnership seems worth exploring. Every service gap feels like something you should fix.
But saying yes to everything is not generosity. It is strategic self-harm.
A charity that chases every available funding stream may end up running projects that do not fit its mission, confuse staff, exhaust volunteers and make the organisation harder to explain. A small business that copies every competitor may lose the thing that made it distinctive. A team that keeps adding initiatives without stopping anything is not becoming more ambitious. It is building a museum of unfinished intentions.
Strategy requires trade-offs. What will you not do? Which customer or beneficiary will you prioritise? Which projects will you pause? Which “nice idea” does not deserve resources right now?
The strategy is often hidden in the no.
Tools to use
Use to keep progress, blockers, decisions and next steps visible.
In the Trenches Weekly Check-In Dashboard
Use to stop scope creep and active problems from becoming informal chaos.
Change Request and Issue Log
Use to capture lessons during delivery, not only after the damage has become educational.
Start-Stop-Continue Retrospective Template
“Plans are only good intentions unless they immediately degenerate into hard work.”
— Peter Drucker
Recommended reading & sources
Houghton, J. – Project Management Made Easy
A beginner-friendly guide to the project lifecycle, especially useful for understanding how execution, monitoring and control fit together.
Pace, M. – “Leveraging the Power of Project Team Collaboration”
Helpful for understanding why weak communication and poor collaboration create rework, delay and delivery failure.
Houghton, J. – “Spiralling In: A Case Study on Financial Monitoring”
A useful warning about what happens when teams focus on solving technical problems while forgetting to watch cost, scope and wider project controls.
Carlton, A. – “Outside-In Perspective: PM Overview”
A grounded, “in the trenches” view of project delivery, including status reporting, practical templates and the less polished reality of implementation.
Doerr, J. – Measure What Matters
Useful for small organisations that want to use OKRs and simple performance measures without drowning in metrics.
Kotter, J.P. – Leading Change
Useful for understanding how implementation depends on momentum, communication, barriers being removed, and people being brought with the change rather than dragged behind it.