Corporate web teams are often overloaded with a combination of one-off change requests and large projects.

Teams are forced to find a balance between requests coming from other stakeholders in the business and their own internal web team initiatives.

This state of affairs can create tremendous unnecessary stress and lead to unnecessary work. It can make it difficult to get the right work accomplished – and that includes SEO-related requests.

In this post, we’ll explore how to deal with this quandary by creating and adhering to a project prioritization framework.

The Difficulties Of Project Prioritization For Web Teams

Most corporate web teams include some combination of Development (developing and maintaining the code and systems), Operations (publishing content and making changes), and Strategy (specialties such as SEO, Analytics, UX, and Content) – along with management.

Web teams are typically in a precarious position in a corporate setting as they’re expected to:

• Maintain mission-critical infrastructure 24/7/365.
• Maintain content that may have no stakeholder owner
• Execute as flawlessly as possible on projects that have executive visibility.
• Execute on an endless stream of content changes and technical requests from stakeholders around the business – which likely will not have executive visibility so long as they’re completed sufficiently and in a reasonable timeframe.
• Advance towards improvements in KPIs or OKRs – many of which will be internally driven.

Meanwhile, the team must:

• Keep things interesting and engaging for the web staff.
• Improve team morale and unity & not burn people out.
• Write and maintain documentation & automation scripts in support of all of the other work.
• Demonstrate the value of the Web team to other teams and top executives.
• Demonstrate the value of sub-teams and individuals to the Web team leader and their manager.
• Accurately plan for the right number of humans, with the right set of skills, required to do everything that will be needed in the coming months and years for development, operations, and strategy.
• Be prepared to pivot to new objectives at any time.

Conflict can arise due to having more requests and committed projects than the team can reasonably handle – or even intake and scope.

Simply adding more team members doesn’t solve the issue (and can even exacerbate it) for a few reasons.

Hiring/onboarding can take months, more management is required for more staff, and discreet projects requiring specific staff or skills might only last a few months (among others).

And this all takes time away from the most effective, skilled, and knowledgeable staff the team already has.

Web teams are in a unique position within a large organization because websites have become not just the front door but the virtual headquarters.

As the world has moved online (and accelerated due to COVID)  more employees working from home still need to be seen as productive.

Corporate web teams have experienced an unprecedented increase in the number of requests to publish new things, make minor edits, and deal with stakeholders.

Many stakeholders view a web team as simply order-takers and not strategic partners.

The options are basically:

• Take on every request received, with urgency. This necessarily results in an overwhelming volume of work, burnout, and mistakes.
• An individual on the web team spends much of their time reviewing and arbitrarily deciding on each request – whether to pursue or not and where it fits in the order of priority – and trying to explain to stakeholders why their projects are being delayed or not being worked on.
• A leadership committee reviews requests on a periodic basis and determines which type to support regularly, which new projects to take on, and in what order.
• The team develops and sticks to a rubric or framework for decision making and prioritization, which is used to evaluate requests and prioritize among other commitments. If a stakeholder’s request must be delayed or not acted on, the web team can point to the framework for justification.

These aren’t necessarily exclusive of one another – there is no reason a committee can’t also rely on a framework.

Whatever the method is, it’s important to communicate to the entire web team and external stakeholders so they can understand how and why decisions are being made.

Basic Requirements For Balancing Projects

Before your team can prioritize the work they’re going to commit to, there are a few basics to put in place.

These are the guard rails that guide other decisions and actions and help the team set clear boundaries with executives and other teams.

1. Team Charter

Your web team needs to have a charter in place that includes things like the mission statement, the values that are important, and the general goals for the team.

2. Inventory Of Existing Commitments, Services Provided, And Systems Maintained

Consider a working list of the services the team provides to other teams, the systems and processes the Web team is responsible for, and an inventory of the commitments the team has made to executives and other teams in the organization.

3. Scoping Of Potential New Projects

In case there is a backlog of potential projects already, you can accurately scope the projects to include possible timelines, individuals required, cost, etc. which helps with deciding what projects get worked in what order.

4. Support From Leadership

If corporate leaders do not support the Web team’s ability to push back on stakeholder requests or view the Web team as strategic expert partners, then your team has no chance at maintaining the balance between internal Web-driven needs and the flood of requests a Web team receives.

5. Web Team Roadmap

It’s critical to begin plotting out the projects that are expected to occur at different times in the future.

Some projects are recurring, some are done once and never to be done again.

Some projects must happen within a very specific timeframe.

Some projects are incredibly important, but have no critical due date and are thus deprioritized forever.

For the short-term, consider 6-month or 12-month roadmaps with specific projects identified and the expected timeframe for project completion.

Start with the known date-committed projects, like supporting quarterly product launches or an annual event, upgrading the version of a critical system, or migrating to a new technology to avoid losing critical functionality that will be end-of-life’d by a vendor.

For the long-term, it can be helpful to consider very broad goals in a 2- or 3-year timeframe. How do you want the team to be operating that far in the future and how is that different from today?

A Framework For Project Prioritization

The following represents a draft of a framework that can be used to prioritize web team projects and requests.

Think of this as a starting point, but consider what is most important in your organization and with your technology stack – and consider what buckets make the most sense for your team.

Highest

Keeping The Lights On (KTLO) – Addressing production bugs impacting large numbers of users in significant ways and necessary updates to critical systems.

These activities are necessary for everything else on the list and become the very top priority when they occur.

Examples might include:

• CMS-critical infrastructure updates.
• Website or section is down with a Status Code 0 or 5XX.
• Broken links.
• Other UI on mission-critical web pages.

High

Executive Special Request Projects – Projects that a VP or other top executive is asking for, even if it may not seem likely to move the needle on a stated business-critical KPI.

In practically every organization, the most important thing you can do is support and trust your executives.

In some cases, working on these projects will mean not working on other projects and potentially not hitting some KPIs.

If a trade-off with other work will be required, it’s important to let the executive know what we won’t be doing to act on their request so they can make an informed decision.

The trade-off KPI that you might now be less likely to achieve could become a stretch goal.

Examples might include:

• Redesigning the homepage.
• Redesigning site navigation.
• Developing a microsite.
• Adding visual bells and whistles.

Business-Critical Projects – These are projects necessary for the business to continue operating.

Typically, these requests support stakeholders outside of the Web team.

A top executive might have visibility into these projects, but it’s not their pet project.

Examples might include: Dealing with acquired websites, product renaming, and launches, fixing analytics for existing reports/use-cases, legal-requested changes, retiring old domains & websites, updating an annual event website, publishing new blog posts, making edits to critical webpages, implementing cookie notices & accessibility standards.

Medium

Web Team Initiated Projects – Projects that advance a Web team towards their business KPIs and “doing the right thing” for the business.

Examples might include: Optimizing for conversion rate, improving user experience for prospects, bringing a website up to speed with competitors for areas like resource centers, improving product or free trial pages, A/B tests, or improving site navigation.

Web Team People Projects – Projects that demonstrate the Web team’s value or improve team culture.

Examples might include: Quarterly on-site/off-site meetings, quarterly meetings with other business units, monthly analytics reporting, all-hands meetings, virtual or in-person coffee, games and team building activities, creating T-Shirts/mugs/swag for the team.

Enabling Projects – Projects that automate or free-up Strategy, Development & Operation time to enable the Web team to have more time for other projects.

Examples might include:

• Website/domain footprint reduction.
• Component-izing HTML areas.
• Automating sitemaps.
• A redirect management tool.
• Jira clean-up.
• Improved processes with other teams.

Low

Non-Critical Bugs – These are problems that need to be fixed, but they might not be impacting business KPIs quite yet.

Examples might include:

• Production bugs experienced by end-users on minor pages.
• Fixing analytics issues to enable future reporting use-cases.
• Improving UI for a subset of device types.

Non-Critical Improvements – These are improvements to the site that needs to happen, but not necessarily immediately.

Examples might include:

• Eliminating redirect chains.
• Non-critical A/B testing.
• Site speed optimization.
• Non-critical user testing/feedback/surveys.
• Non-critical bugs not seen by users (such as bugs on internal interfaces or redirects missing analytics tracking).

Other Stakeholder Requests – Projects being requested by others that are not critical for the business or Web team KPIs and that are not advocated for by Executive leadership. Working on these projects can be helpful for improving relationships across teams if there is capacity available.

Depending on your particular team and organization, some of these areas will be a higher or lower priority – or the tasks might be completely different from what is described here.

Assumptions And Other Considerations

To implement a project prioritization framework, certain assumptions are required. Some of these may include:

• There will always be a large backlog of potential projects. There is always more that can be done to a website, more optimization, more automation, more changes, more maintenance.
• Not all projects are of equal importance. Some sound good, some are advocated by top executives, some will advance the site or team towards a KPI.
• Some proposed projects are a bad idea and should not be worked on.
• A Web team can’t and shouldn’t act on every request they receive.
• The priorities of the broader team that the Web team reports into – whether marketing, growth, or something else – should guide prioritization and decision making.
• Data accuracy is paramount when the data is used to justify projects, in prioritization, or to measure success. Thus projects to improve or maintain data accuracy must be elevated to enable prioritization.

Wrapping Up

Web teams simply can’t do everything they want to do, and everything is being asked of them by their stakeholders – including those in SEO.

In order to decide what the team should work on immediately, what to work on eventually (and what requests or projects to never touch), set up a framework.

By setting up a framework for decision making, you’ll avoid the pitfalls of constant arbitrary one-off decision making and help your team stay aligned and motivated to accomplish the most important work for the business.

More resources:

Featured Image: Matej Kastelic/Shutterstock