How to Execute Well: Project Management for Ops Teams
Because your strategy is only as effective as your execution
In earlier posts, we’ve looked at defining the overall mission for your ops team, budgeting your time into workstreams, and how to prioritize for maximize impact.
Follow these steps, and you can be confident you’re doing the right work.
But doing the right work isn’t the same as doing things right. And this is where many teams fall down.
There’s nothing magical about great execution. But doing it consistently requires a clear process and a disciplined team.
The Stages of Work
As a general rule, the following stages apply to any task you might work on.
Initiation: Identifying or proposing potential work
Triage: Assessing and clarifying the task
Prioritization: Determining if and when the task should be executed
Execution: Doing the work. This may have sub-phases:
Design: Defining requirements and designing the solution
Build: Configuring systems or creating the deliverable
QA/UAT: Testing the work to ensure it meets requirements
Enablement: Training and communication
Go-Live: Deploying the new solution or process
Monitoring: Continual observation and intervention to ensure impact
Let’s review each stage in detail.
Initiation
Initiation is how work gets started.
Any ops team will inevitably field many incoming requests, but to avoid being pigeon-holed as a service department, make sure you’re also starting with business KPIs, and doing your own holistic evaluation of what work is most important to do.
Triage
It’s easy to work reactively or try to rush a task without considering its true scope or potential downstream ramifications.
Triage forces you to slow down and evaluate the task critically, identify missing information, and enforce project management system hygiene standards.
Triage tips
Effective triage relies heavily on your common sense, good judgement, and experience. It improves with practice.
But here are some tips that can help.
Enforce your intake process
Teams often need reminders and reinforcement to follow the intake process.
If stakeholders initiate work through unauthorized channels (Chatter, Slack, etc.), this is your chance to push back.
If you aren’t 100% consistent, people will do what’s easiest for themselves and your execution will suffer.
Watch for feature requests masquerading as bugs
Sometimes people consider something "broken" if it isn't working according to their expectations.
This creates pressure to fix it quickly.
But what they consider broken may just be a requirement that was never previously considered.
Collect all the information upfront
If a request is vague or lacking detail, request it now before starting work.
This is particularly important for marketing campaigns with many moving pieces.
For example, if your stakeholder needs to provide a subject line, a feature image, a sender name (etc.)—make them do it upfront, so you aren’t blocked later on.
Enforce project management hygiene
If your project management system is a mess, you most likely aren’t executing well.
There’s no need to overcomplicate things, but you should insist that all tasks/cards have a clear title, a sufficiently detailed description, an assigned owner, and any labels needed for filtering / reporting.
Reinforce this with your ops team members so it becomes second nature.
Identify the root business need
Stakeholders often come with a specific solution in mind. But this may not be the right solution.
It’s your job to dig deep into the root pain / business need to ensure you solve the right problem in the best way.
Be judicious about “quick wins”
I define a “quick win” as a high impact task that takes 30 minutes or less.
These are typically faster to execute in real time than to backlog and prioritize for another day.
However, you can easily get bogged down in quick wins that aren’t so quick and lose sight of your strategic priorities. So evaluate them carefully.
Assigning a T-Shirt Size
We use the "T-Shirt Size" methodology to estimate effort.
The purpose of this estimating methodology is not to be precise—it's to be reasonably accurate and fast.
Use your best judgement and don't worry if you aren't right. Just learn, and use the knowledge to be more accurate next time.
As a rough guide for translating effort to hours:
Extra Small (XS): 1 hour or less
Small (S): 1-5 hours
Medium (M): 5-10 hours
Large (L): 10-20 hours
Extra Large (XL): 20+ hours
Prioritization
Tasks that aren’t executed immediately as a quick win or rejected due to lack of impact go into a backlog for future prioritization.
For some teams, prioritization might occur on a quarterly basis, when preparing OKRs, but could happen more frequently if you’re using a sprint framework.
So how do you prioritize?
There are many frameworks you can use—Jeff Ignacio has a great roundup here.
In my current stage of company (~400 people), I generally prefer to keep prioritization as simple as I can, focusing on big rock initiatives clearly aligned with our corporate OKRs. Common sense is also a useful guide.
Execution
Execution can be simple or complex, depending on the task. Typically it should be broken down into the following sub-phases.
Design Phase
Design phase ensures the work is aimed at the right outcomes and that all stakeholders are aligned on the work to be done. That means everyone agree on what "success" looks like.
It can be tempting to go fast by skipping this stage and to start building in tools.
This is the wrong decision pretty much 100% of the time.
It typically results in more re-work and ultimately slows things down when the end result doesn't meet expectations or achieve the intended impact.
The requirements, business logic, and technical solution defined during this phase should be captured using the appropriate level of documentation. Don’t put it off.
Build Phase
The build phase is when the work product or deliverable gets made—i.e., you configure the system, you design the process, you build the report, and so on.
Some tasks may not have a build phase (e..g, the task is more conceptual, like defining a KPI or providing information).
QA / UAT
As a general rule, any new system configuration should be tested before being activated/released.
How much testing should you do? This is a common-sense judgement based on the risk / impact of potential errors and time required.
What’s the difference between QA and UAT? Both are aimed at ensuring that work meets its requirements, but I define QA as testing done by ops and UAT as hands-on testing from users / stakeholders.
Enablement
Even a perfectly-designed and well-tested solution can fail if users don't understand it or know how to use it. So your enablement plan is a vital part of the work.
Although formal training might only happen near the end of a project, your communication and change management efforts should span the entire project.
This is a detailed topic, so check out my complete guide to change management here.
Go-Live
Deployments are fraught with peril and need careful planning to avoid system disruption or unintended regression.
Pay special attention to data updates that might overwhelm system integrations and create backlogs. Evenings and weekends are your friends here.
Monitoring
This phase is about ensuring impact.
We added it as an explicit step to our process relatively recently. It’s something we always knew we should do, but without a formal step and process, it relied too much on individual discretion.
Monitoring means you proactively ensure a system is functioning without waiting for user bug reports.
It means being able to answer the question in 6 months, “what did this actually do for us?”.
You may need multiple interventions and iterations to ensure a project is actually achieving the intended impact.
Final thoughts
There’s obviously no one-size-fits all process here. You may need to tweak things based on the size and maturity of your team, your scope of responsibility (e.g., whether business systems live inside ops or in a separate team), and your business context.
But the work you put in to develop rigour here will pay huge dividends in the quality of your output, the impact you have, and your credibility in the organization. Of course, it also makes work way more enjoyable!
Stay tuned for a follow-up post where we’ll look at how to execute this process within a project management system.