I lead operations and operational infrastructure at the business I work for. Recently, I drew up a plan covering the parts of the business that needed a clearer structure: how decisions are made, how work moves between departments, how we support people and how we understand the cost of delivery.
The plan brings team operations, development, client retention, sales and time management into the same conversation. Each affects the others. A project can be sold with a sensible budget and still become difficult to deliver if the scope, available time or responsibilities are unclear.
When I presented the plan, the business accepted it straight away and agreed to its full implementation. That gives the work a clear direction. It also means the next step is to turn the proposals into routines that people can use throughout the week.
Starting with effort and delivery
One of the problems I wanted to address was the relationship between the time spent servicing a client and the service they actually receive. A team can put considerable effort into a project while the agreed deliverables remain unfinished. That deserves a closer look at the process around the work.
My starting point was to connect commitments to capacity. What has been sold needs to translate into an understood scope, a realistic allocation of time and people who know which parts they own. Those connections also make it easier to see when a project needs another decision.
The plan’s wider aim is a profitable business with a team that can develop its skills and deliver good work. I wanted the operational structure to support staff wellbeing, client outcomes and the commercial side together. Improving one while repeatedly putting pressure on another would leave the same problems waiting elsewhere.
Giving decisions a route through the business
I proposed fortnightly meetings between team leads, with operational decisions collected into a monthly document for director review and sign-off. Business-critical decisions need a quicker route, but ordinary improvements should have a regular place to be discussed and followed through.
That gives knowledge from the departments a way to reach the people deciding the business’s direction. It also gives direction from the directors a way back into practical work. A decision about the type of project we should sell needs team leads to work through what that means for delivery.
Each operational change has a champion responsible for helping it happen. The champion can be a team member with the right knowledge, supported by the relevant lead. Assigning that responsibility makes it possible to return to an improvement and understand what has moved forward, what is waiting and who needs help.
Documentation that supports the next person
The plan calls for documented marketing and development workflows, including the deliverables and estimated time associated with each stage. I want someone joining a department to be able to understand how work is carried out without having to reconstruct the process from messages and conversations.
These documents need to stay current. When a better approach is agreed, the process should change with it. Otherwise the written version and the working version gradually become different things, and a new team member inherits an explanation that no longer fits.
I proposed a central Monday.com board linking to the process documents, alongside departmental boards for actionable goals. An action should explain who is responsible and why it benefits the business. That keeps the operational plan connected to the work people are actually taking on.
Connecting sales to delivery
Sales confidence depends partly on being able to explain what the business can deliver within a particular budget and timeframe. I included internal pricing bands in the plan so that a smaller project and a more complex build could have clearly different expectations.
Those expectations cover practical details such as page counts, design complexity, content imports, ecommerce requirements and integrations. The point is to make the relationship between price and deliverables understandable before a project reaches the team. A lower budget needs an appropriate scope and method of delivery.
The delivery roadmap starts with a project handover involving sales, design, development, project management and operations. The specification is discussed, budgets are separated between the relevant teams and milestones are given time in Pathfinder. I also mapped design, development, content population, quality control, retrospectives and ongoing support so that the transitions between them could be considered.
Building the information behind the decisions
I built Pathfinder Analytics to support time tracking and projections. It is part of the infrastructure behind the plan: a way to connect clients, projects, services, budgets and the time needed to deliver them.
Project and account managers need to know where capacity is available and how much of a project’s budget remains. Operations needs to understand patterns across services and departments. Directors need a view of income, costs, sales opportunities and the risks attached to future work.
Those views need to relate to one another. An optimistic forecast can look attractive while the schedule has no room for the work it assumes. A project can appear comfortable against its budget while time entries are incomplete. Bringing the information together gives us a better basis for discussing those gaps.
Keeping the plan active
I included a regular operational cadence in the implementation: progression conversations, monthly director meetings and catch-ups with sales and SEO. Scheduling the meetings ahead gives the work a place in the diary, while process boards give the decisions somewhere to go afterwards.
The plan also makes room for staff development, recognition and new methods of delivery. AI, automation and improvements to the client experience belong in the same ongoing review as capacity and profitability. As the work changes, we need to reconsider which skills and tools will help us deliver it well.
I drew the document up as an evolving specification. Its approval is the starting point for implementation, and the processes will need to be tested against real projects. I want us to be able to return to the plan, see what is working and change the parts that need another approach. That is how I expect the operational infrastructure to remain useful as the business grows.