Chapter 3

Form Your Project Team

Summary

Web projects are shaped by the people involved in decision-making. You can help prevent latestage rework by making sure the right people are in the room from the beginning.

Does This Apply?

You need to know who your web team is – who is a good fit, who you need to hire, and what roles they’ll be playing as you take your party on this exciting new web adventure – from the beginning. Roles may change throughout, and the individuals will come and go (especially with longer projects), but you need to have an idea who you can count on, no matter the project.

Narrative

There’s a concept introduced in tabletop games like Dungeons and Dragons (and further codified through video games like Final Fantasy) called “party balance.” Because these game systems are built around a set of codified skills, characters with complementary skills tend to make the strongest party, as they cover for a wider range of potential encounters. Having too many people in one discipline makes you incredibly strong at one part of the game, but vulnerable in others; a party of sword-swinging fighters might be able to take and deal a ton of damage to a wandering group of goblins, but they provide limited options for longevity (very little natural healing power) and a lack of range for distance fighting.

This is not unique to wizards and warriors, obviously. Professional sports teams are often focused on exploiting the weak points of their opponents: a basketball team that can’t shoot from range will see their defenders fall back closer to the basket, meaning the closer scoring options are better defended. The best quiz teams collect people who can cover multiple disciplines. The most successful (and most exciting) communities are those that provide a little something for everyone.

So too are your businesses. The web process, more than any other creative outlet, balances the free-form thinking of creative writing and graphic design with the nuts and bolts of product design, which means you need a varied and complementary team to help merge business goals with future-focused design and technical competence.

You need a little bit of everything to build a website. Let’s talk about what those “little bits” are.

Episode 3: Form Your Project Team (w/ Patrice Embry)

Corey and Deane talk about the roles missing from most new project teams — namely, the idea of a user and product advocate. Then, Patrice Embry joins the podcast to talk about forming a project team. And, of course, we talk about sports metaphors.

37:12 | Patrice Embry

Past Episodes

Stakeholders

First of all, there are the people who get to make decisions. Stakeholders.

A stakeholder is someone affected, whether in reality or perception, by a project. On your project, you’ll potentially run into one or more of the following types of stakeholders:

  • Those Who Affect: Here’s a quick list of people who, without a doubt, affect the decisions and outcomes of your web project: the person or group who controls the organization’s goals and direction; the person or group who controls the money; the person or group who controls the content; the person or group who controls operations.
  • Those Who Are Affected By: This is where the concept of a stakeholder – and a stakeholder’s actual stake in decision making – begins to get a little fuzzy. For example, your new website may affect the sales department’s ability to do their job, but whether or not you make decisions based on the sales department’s needs (what we’ll call a consulting stakeholder) or if their process adjusts based on changes to the existing web process (what we’ll call a passive stakeholder) determines whether or not you bring them to the table through the entire process.
  • Those Who Perceive Themselves To Be Affected By: These are people who are pretty sure they need to be a part of the decision, but in reality have little bearing on the overall project. For example, meet Francis Jellybottom, an adjunct professor of history who has (in the past) run his own section of the university website and currently maintains his own separate blog on Medium. Francis wants so very badly to be a part of the web process. This may be because he has great ideas on how to integrate his work into the new content plan. Or this may be because he’s concerned about how he’ll have to change his methods to facilitate a new site. He probably doesn’t garner a seat at the decision-making table, especially if he’s represented by another ranking stakeholder. But he does warrant an audience with the stakeholder team, because he’s a person who will make waves.

You can see from this that a web project has four tiers:

  • Affecting stakeholders
  • Consulting stakeholders
  • Passive stakeholders
  • Perceived stakeholders

Whether or not these roles overlap into the same person or whether you have entire teams at each level, what’s important is that all of them are heard.

It’s easy to think that we can consult our bosses and the people who sign off on budgets and be covered, but the stakes for a new website go deeper than just a corporate decision. The website is a thing that will touch the lives of all levels of stakeholders, and while someone like Francis Jellybottom might not have the power to approve a formal request for functionality, he can sure shift public opinion and gum up the wheels on whether or not the new intranet is adopted, or whether new content workflows move smoothly.

Whether or not stakeholders have an actual stake in the project is irrelevant: the perception of having a stake in the project will lead them to take action.

Building the Web Project Team

When we enter into the discovery phase of a project, the question we get most often is “who should we invite to the initial meetings?” This is a tricky question for us because we do not yet understand the organizational hierarchy and therefore cannot reliably ask for specific positions or people.

Understanding the people involved in decision-making is further complicated by the fact that your group of main stakeholders is not necessarily the same as the team you will use to do the actual work. In most cases, your stakeholders inform decisions, and help determine constraints, and some serve as a part of your web team, but they are not themselves the web team.

Instead, the web team needs to take the concerns of stakeholders, mash them with documented business goals, weigh them against user needs, and make real decisions about real aspects of the website.

Your web team needs to represent two distinct mindsets:

  • Business Strategy: This website needs to serve the greater communication needs of your organization. It needs to provide a path to some kind of business or organizational goal.
  • Project Strategy: In order for the site to work well, we need to successfully execute certain pieces of the project, and we will need to maintain those pieces into the future. We need people who can help us take on the relevant layers of the stack that we talked about in the last chapter.

In other words, your web team should include people who can make business decisions, and people who can make project decisions.

Here’s an example. Let’s say you’re a medium-sized public liberal arts university. You have limited development capacity, but you definitely have an IT department that will maintain the site after launch. You despise the CMS you’re currently using, and so you believe you need a full-stack approach, creating a new site from the ground up.

Who do you need to invite?

In this example, you need people who can represent the major areas of the university – especially those who generate income and drive engagement. Someone who can speak for the needs of the admissions department, someone who can speak for the needs of the dean’s office, and someone who can speak for the needs of marketing. This represents business strategy, and might look like:

  • Director of Marketing
  • Director of Admissions
  • Vice President of University Relations

In two cases here, you’ve added in the actual decision makers – the Director of Marketing and Director of Admissions – and for the other, you’ve got a representative who can speak for both the dean’s office as well as for the entire corporate suite.

These leaders will be helping with decisions, but often won’t be doing a lot of the actual project work, so your web team also needs someone who can handle the project itself: strategic project decisions, design and development, governance planning, server and integration management, and more. For our university example, let’s assume this means we’re using:

  • Director of IT: Will help determine server arrangement, develop a plan for post-launch maintenance, help integrate external services, and have a hand in helping choose a CMS.
  • Director of Marketing: Will begin developing workflow for the new site (and the marketing that leads into it) and will begin figuring out the viability of hiring someone dedicated to the new site install.
  • Web Content Specialist: Will be tasked with making sure the site handles the content required for the new site, will manage migration, and will provide high-level strategic decisions
  • External Web Development Firm: Your designer is busy with the work they are required to do each day, and your IT department doesn’t have capacity to build a new site, let alone break down a custom CMS install. You’ve decided to hire a firm to help here.
  • External Digital Marketing Firm: Maybe you are thinking of launching the site with help from a digital marketing firm, and keeping them on for a few years to develop better content.

In this example, there are only five people from the university – as well as representatives from two external firms – involved with the web decision process. Yes, they may delegate tasks to other people, but the core web team is five people because five people are all they need. Some organizations may need more.

One last quick note – while this core team is responsible for making some deep decisions, there’s also what Lisa Welchman calls the “distributed digital team,” which consists of your day-to-day editors, product specialists, production designers, and more. We will talk more about these people in future chapters when we talk about governance and maintenance.

We can never tell you exactly who should be in the room, but we can offer a few guidelines based on our experience:

  • Err on the side of a smaller representative team. There is rarely a need to send every member of a specific department, such as the marketing team, to be deeply involved in every meeting and decision – in fact, doing so can severely skew decision making toward that one department.
  • Make sure business goals are represented. If a site is being rebuilt to provide a better experience for the roaming external sales team, make sure someone from that team is represented as a part of the decision-making process, even if they’re not explicitly invited themselves.
  • Make inclusivity a part of your process from day one by creating a diverse team that, at minimum, represents as close as possible the full scope of users who will use your site or encounter your project. People who can uncover biases, stop troublesome messaging before it’s released to the world, and provide a more inclusive discussion around how the site should function.
  • Understand that opinions come from beyond the corporate suite. What are front-line employees – call center operators, warehouse workers, or forum moderators – hearing about the current site, and what would make their job, and the experience of the people they come into contact with every day, a lot easier?
  • Implement a path of accountability. While any major web decision is going to ultimately come down to a decision between business goals, budget, and capacity, there needs to be someone (or a very small team of someones) who can make hard and fast decisions. Otherwise, we’re looking at a very expensive and demoralizing “website by committee” approach that will no doubt end up as the basis for a conference talk on what not to do.
  • Take each person’s workload into account. As much as you would love to have a perfect team, people are busy. You want someone who can attend most meetings and help provide guidance to both major and minor decisions. You don’t want someone who is maybe more knowledgeable but never available. They will show up three meetings after a decision has been made and begin trying to refigure it.

With this team, you should be able to look at the major stakeholders and say that, indeed, you have most holes covered. It will never be perfect, but it will make things happen. You can think a web project to death, to the point that everyone’s tired of it before it launches. Choosing the right people is key to making things better.

When the Right People Aren't Right There

A new web project, whether it’s a redesign or a new site or a major functionality overhaul, is going to create a bubble in your capacity. Which means, for a short time – or a long time, depending on the size of the project – you’ll need to supplement your team. In that case you have three options:

  • Create from within: Pull someone from another department or discipline to step in, or promote someone to a position where they’re now in charge of some element of the new web project. This can be incredibly rewarding for someone who has a vested interest in the site, or has a real desire to move up into that kind of work – and it can be an affordable answer – but it is rare to find this kind of perfect fit. Often, you’re asking someone to do something they don’t have time to do, something they weren’t hired to do, or something they don’t even really fully understand.
  • Hire from outside: If your team looks as though it’s going to need someone not just for the project, but for the long haul, think about hiring that person before the project starts. This works best if there’s a long-term plan for continuous work – someone who will take on a new position focused on site governance, for example. On the other hand, it’s not a great idea for a project that will wind down almost immediately after launch, leaving that new hire with …
  • Bring in an external partner: This is the agency or consultant model. You hire an outside person or firm who specializes in some – or most – of the project stack. This could be a single copywriter. This could be a design and branding firm. This could be a full-service web agency that will help push you from initial concepts through to digital marketing. If you need to fill a role on your web team, there is someone out there who specializes in it.

You’re going to need people. But, you’re going to need people who can professionally execute the work required of them. A web project is an expensive endeavor, so providing the right people at the start isn’t just an issue of craft: it’s an issue of budget and responsibility.

Working with External Partners

External partners – web shops, or copywriters, or off-shore IT consultants – are at their core external. They may be experts in their field, but they will rarely (if ever) become experts in your industry or organization. There are benefits to this – this means they can look at business decisions without the stain of history or preconceived notions of industry best practices – but it also means there will always and forever be a bit of an industry-tied language barrier.

This is the balance of external vs in-house: You trade organizational familiarity for stack-level expertise. Your budget (from a strictly monetary standpoint) gets a bit bigger, but in exchange you free up your internal staff’s time and energy for some of that industry- and organization-specific work.

Most organizations do not have the luxury of a fully-functioning web content, design, and development team, which means most organizations are forced by capacity alone to reach out to external partners for help. In these cases, there is always a cost … but there’s also a cost if you try to hire your own employees or take time to teach your IT team how to develop in a specific CMS, so “cost” is all relative.

Choosing a Leader

Just like web projects need to be driven from both business and production mindsets, web projects need to be led by both someone who can push the full vision of the site and someone who can drive production of the site.

You need a project leader, and you need a project manager.

On rare occasions, the two can be the same. Both the 1967–68 and 1968–69 Celtics were able to win a championship by relying on a single player-coach (Bill Russell) who both led on-court and off-court. Because we so often work as an external consultant, we rarely encounter this – the production is handled by a project manager on our side, who works with the project leader on the client side. But even with internal projects you most often see a natural separation between the person who is driving decisions – the director of marketing, the vice president of public relations, the brand manager – and the person who is driving production – an internal project manager, a director of IT, or even at times a project management consultant.

To define these roles:

  • Project Leader: The role of the project leader is to be the person responsible for the success (or, ugh, failure) of the website. This could mean anything from managing the organization’s expectations, to making decisions on the core web team, to giving feedback and direction to features and strategic decisions. Regardless, there’s one thing that’s always true: this person is going to make the new website their life for a little bit. Or a long time. (Usually the latter.)
  • Project Manager: The role of the project manager is to be the person responsible for keeping the project on a timeline and managing the different resources required for a fully functioning site. They are connecting external team members in order to make something happen. Where the project leader is responsible for making it valuable, the project manager is responsible for making it work.

Ultimately, one of them decides what needs to happen, and the other decides how it’s going to happen. Both of them work together to drive the vision of a common web plan.

Your project leader is the person who is going to help finalize scope. Your project manager … well, they’re going to help you build your web project plan.

And speaking of web plans, let’s get to work making one.

Inputs and Outputs

Input for this will depend on the portions of the project stack that you’ll be working with, but most likely you’ll need to understand the availability and skill set of potential members of the project team.

Output could include everything from creation of a formal web steering committee to a project organizational chart that outlines who will answer to what portions of the project. Once this team is figured out, another output is a weekly status meeting with those who are considered project leaders.

The Big Picture

Making sure you have the right people – and making decisions to bring in additional members from within or outside the organization – is most likely to happen at the start as you’re formalizing scope and creating an environment for project work to actually begin.

But don’t think for a second that your team is going to be 100% from the start. The team you start with is rarely the same one you end with, either because someone is only needed for one part or another, or because the volatile nature of hiring people and keeping them happy is often a risky endeavor.

Staffing

This section often talks about who is tasked with executing this phase or stage of a web project, but in this case the entire chapter is about the act of finding and hiring staff in order to build your web team. Which, we guess, means you are the person. You’re reading this book, after all, which means, more often than not, you’re in charge of some aspect of the web project.

Resources

Books

Podcasts

Articles

Presentations