How to Run Projects on Time—and Keep Your Sanity

By Lauren Rabaino

This. This can be your new life. (Jennifer Stahn)

Deep dives on project management, process, workflow, newsroom culture & more

A happy team is one that is productive, effective, and fulfilled in its work. It’s hard to get there when you’re balancing competing priorities of many different sites, sections, or editors, alongside the company's needs to scale and platformize. The Editorial Products group at Vox Media—just one small subset of the larger product team—deals with the realities of this daily. We have people working on platform tools and others embedded in newsrooms, working alongside reporters. There will always be chaos when you mash up the demands of the news cycle with the product development cycle, and my role as a director of this team is to remove as much uncertainty as possible.

To mitigate the chaos, we’ve developed some processes together over time, usually when we feel our happiness meter start to dip. Conversations like “I’m building my first graphic and I feel alone and no one is helping me and the docs are incomplete!” or “I feel so disconnected from the rest of the team being in a different city” or “I don’t get what criteria your team is using when you say no to my projects!” are all the catalysts for change.

No matter the size of your newsroom or data desk or graphics team or product group, these are three important practices we’ve developed that can keep a team united and keep your projects running on time.

Document All the Things

Documenting everything for yourself, and the people who rely on you, helps in so many ways. It eases onboarding, instills trust among the team, keeps stakeholders informed, and holds the whole team accountable to our objectives. Most importantly, it improves team happiness. Yep, docs can do that.

Say you have a teammate who’s unhappy about your design review process. She really wants to add a step that would make her work easier and more efficient. Instead of making an amorphous promise like, “we can work on improving that over time!”, you can open up your process document, add the step to it, and send it around. The message: a thing has changed, let’s all act on it immediately. Canonical, centralized documents make decisions more meaningful and easier to implement.

This is especially important with remote teams, where habits and processes might develop amongst the co-located members, leaving others feeling disconnected. Writing it down creates a shared way of doing things that everyone can see and contribute to.

Some examples of things to write down:

• Mission: What is the high-level vision we’re working toward, and the quarterly objectives to get us there?
• Working on projects: How do you initiate them? What questions do you ask from the start? What tools should be used to track work, and what are the best practices and expectations for using those tools?
• Evaluation: How do you prioritize your work? For us, it’s a rubric that weighs audience growth, editorial impact, storytelling innovation, and revenue potential. Without a clear sense of how you prioritize, it can seem arbitrary to your stakeholders, and easy for your team to make exceptions that set you off course from your goals.
• Communication: How to communicate with stakeholders, be it editors or a product team or sales, in a way that is consistent, easily accessible, and honest. What’s your practice when your team messes up or something breaks? How do you solicit feedback on designs? (I touch on this in the next section). How do you let people know what kind of work is upcoming, and what’s been accomplished?
• Technical: How to set up your engineering workstation, and get started with projects.

Yes, writing docs takes time. You have to do it regularly, and you have to go back and update your documents often. That’s not the job of the product manager alone. That’s the job of the entire team. We solve for this by holding a Documentation Day, a full day of doing nothing but writing.

Here’s how:

• Every time a new person comes onto the team, have them write down every question they have. Everyone else should do the same, writing issues down as they stumble on problems or undocumented processes, or old docs that need updating. You can keep a running Google Doc or a lane on a Trello board for things to document.
• Once that list gets long enough, work a Documentation Day into your team planning or your sprint. The day starts with a kickoff, where we go through all the things that need to be documented, to jot down quick bullet points and goals for each assignment.
• Everyone gets to write something (or comment code, or create new templates/styleguides—not all documentation is in the form of text docs)—and every assignment also gets a peer reviewer. The peer reviewer’s job is to make sure all the questions have been answered, that the structure of the document is organized really well, has a good starting point, moves you through coherently step-by-step, and includes supporting links when necessary.
• Once all the docs are written and peer reviewed, collect them in one place where everyone can easily access them—a wiki, a Google doc, some other searchable tool! We use one centralized Google Doc as the place that links to all of our documents by topic. We write most of our how-tos in Google Docs, and technical docs go into GitHub wikis and READMEs for their corresponding repository.

Structure Design Reviews for Maximum Joy

Here’s another tricky spot, where happiness can evaporate quickly. When any groups of multidisciplinary people work together, a big part of the process is back-and-forth feedback, for revisions. This design review with stakeholders can drag on forever. (And by stakeholders, I mean your collaborators, people who rely on you, and whom you rely on.)

Here are our rules for keeping design reviews on track (stolen straight from our internal documentation):

• Establish the points of focus to discuss. If you are presenting sketches, say that this is a meeting about concepts, not fidelity. If you are showing a polished logo, the minutia of type kerning may be discussed. This helps focus the discussion.

• Avoid vague questions like “Do you like it?” or “What do you think?”, as they will trap the discussion in opinions rather than project goals. Strive to ask targeted questions that test the goals of the project. For instance: “Does this feel like The Verge?”, “Does this interaction feel clear?”, “Do these icons and colors feel like they are part of the same design system?”, “Is this typography and typeface selection working for this subject?”

• Don’t try to solve design problems in the presentation meeting. Group design reviews are great for identifying problems, but not great for solving problems. This is only the time to present and discuss what is working or not. The meeting will give you the information you need to solve design problems later.

These rules have changed the way we talk about our work and have helped us work through issues more quickly. If someone tries to jump into a meeting who doesn’t have context or wants to solve design problems on the spot, we can step it back and make sure we’re focusing on the problems at hand. When someone says, “We should do a mosaic-style grid with large, medium, and small images sprinkled throughout” we can say, “Let’s talk more about that. It sounds like you’re looking for more variation and hierarchy?” and take the conversation to a place of goals.

Let the Humanity Shine Through

Part of keeping a team happy is making sure your teammates know more about each other than their file-naming conventions or code-commenting style. We’re all humans, and it’s healthy to foster team relationships in a personal way, which, again, is super important with remote teams.

Here’s a structure for a weekly meeting, Google Hangout, or Skype chat that brings everyone closer and helps them look back at their progress.

1. Give everyone time to show and tell. Every Friday morning, create a new Google Presentation that anyone can add slides to. At the meeting or hangout, those who added slides get to talk. People can share everything from an introduction to their children, to their favorite weekend hikes, to a personal time-management skill they learned, to their favorite ways to reduce pageload. It can be one slide, it can be 10; it can be one minute, it can be five; it can be personal, it can be work related. It takes you out of your normal work mindset, loosens everyone up a little, and brings everyone closer. We’ve made a meeting like this work for up to 20 people, which is probably as big as it can get.
2. Reflect on the week. Doing retrospectives every week or at the end of every sprint is super important, but for large teams with complex projects, it’s hard and incredibly time-consuming to talk about every single thing that was built or shipped. Instead we use a more casual, two-step approach. First we “damn the things,” where anyone can talk about what went wrong during the week (no badmouthing your teammates!). Then we do shoutouts, where we can call out anything that went really well, or teammates who did awesome work. Based on this part of the meeting, we can schedule project-specific retrospectives if there are clearly certain issues we need to talk through.

The format of our Friday hangout is a mashup of things stolen from Editorially and TribApps plus a little of our own spice—and now you can steal it and remix it too.

These three practices haven’t been in place since the start, and they’re certainly not the only processes we employ to keep each other sane. The team has shaped these ideas over time, always in response to unhappiness and because we have a hunger to make things better. We have an open and healthy culture of talking about what works and what doesn’t. The team knows that the leadership level works for them, not the other way around. It’s the job of the directors to give everyone what they need to be effective, productive, and fulfilled.

We experiment with this stuff constantly. What I’ve outlined above is what we have in place today, but it was different three months ago and will be different three months from now. The important thing is that everyone on our team is empowered to refine, adapt, and iterate to find something different or better. And once we’ve done that, we write it down and start the cycle over again.

Read Full Story from Source https://source.opennews.org/articles/time-and-sanity/
This article by Lauren Rabaino originally appeared on source.opennews.org on September 15, 2015 at 08:15PM