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

Whether you work for a nimble online-only upstart or a still-adapting traditional organization, odds are good that there are processes in your digital product workflow that could use tweaking. Not everyone knows if their team has workflow challenges (or where those challenges are), but the simple act of discussion with stakeholders and peers in other organizations can illuminate pain points big and small, and ensure everyone is on the same page. Learning how others arrange their workflows can achieve a similar goal, plus give you some ideas for how to remedy those pain points.

At SRCCON 2015 in June, we tried to tackle this issue by asking groups to design ideal workflows for different levels of digital products: one that can stand on its own, one that accompanies a long-term or enterprise written component, and one that is a daily or quick-turn product. While no one team’s workflow proposal was the same, there were common threads. We also heard snippets of these suggestions throughout other sessions and have been attempting to do our own tweaking of workflows at the Star Tribune. These are a few universals we’ve identified.

1. Clarify Responsibilities, Deadlines & Expectations

Clear communication about who is doing what and when is key. Our SRCCON groups discussed different ways to do this, such as setting up a chart listing who’s responsible for what and developing back-out schedules with specific deadlines. One of the groups at SRCCON discussed using a project management technique known as RASCI. This is a process where you determine who is “Responsible,” “Accountable,” “Supportive,” “Consulted,” and “Informed” for each piece of a project.

Here’s a rough example of a RASCI diagram with the color-coded letters representing the various RASCI roles (i.e. R=responsible). Keep in mind that your newsroom might have different job titles and each RASCI role might be different. For example, in our newsroom, a senior editor has to sign off on pretty much all components of a big project, so it makes sense to have them in the Consulted role for each piece.

An example of RASCI roles mapped across a newsroom team

While you’re establishing roles, also be sure to decide up front how you’re going to communicate. Email? Software such as Trello, Basecamp or Slack? Discovering halfway through a project that someone is using a different channel or isn’t getting notifications can wreak havoc.

Everyone involved should be very clear on what their role is, what they’re delivering, and when. Discuss mission statements and goals (more on that below), and make sure everyone is on the same page by sharing early prototypes—even hand-sketched paper prototypes are a good start. Surprises are no fun. Even on quick-turn daily projects, tempering expectations about what can be achieved in a short amount of time is key. Define a time(s) to circle back with reporters and editors for a progress report.

2. Define Your Mission

Part of the setup process should include determining the project’s mission. Usually this will be something related to the key point you want readers to take away from the digital product or the whole project (if there are multiple components). Then look at your product(s) and assess whether or not they are meeting the mission. If something doesn’t fit the mission, that’s an indicator that maybe you shouldn’t waste your valuable time on it.

For example, let’s say you’re building an app that allows readers to look at inspection data for nursing homes. The mission might be something like: “Help readers compare nursing homes” or “Help readers see how widespread problems are at our local nursing homes.” Notice that those two things have very different missions. The first focuses on comparing, so then you would want your app to make it easy to do that. The second focuses on the sheer volume of problems, so for that one you’d want to illuminate that scope.

3. Establish Multi-Directional Communication

Builders, whether that’s a formal developer or someone who is putting together the digital product, need to keep the reporters and editors in the loop about how their work is developing, the reporter needs to give the builder access to rough drafts of the story and updates on the reporting process, and the editor needs to keep everyone apprised of changing deadlines and publication dates. Builders should be involved in the story and understand the reporting—they should not feel as though they are simply filling a request for a fancy, flashy thing. Reporters and editors should regularly review prototypes to help them understand what the outcome might look like. In the long term, keeping reporters and editors in the loop will also help them develop a better vocabulary for digital products and understand what is possible for future projects.

4. Get Broader Feedback

In addition to getting feedback from team members, try to get some outsiders involved. This could simply be others in the newsroom (or other departments) who are not involved in the project. Or you could do formal focus groups made up of readers or others from outside the organization.

Sending a version of your product to someone totally removed from the process can give you a window into the questions the user will have. That thing you made looks really cool, but it also might be really complicated for someone new to the subject. You might never know that unless you ask. This is true even for seemingly-basic things like line charts or bar charts—whoops, you forgot to turn your data into a rate! Thanks for catching that, feedback-giver.

Develop a specific list of questions for outsiders so that you get better feedback than simply: “You forgot a comma in this text” or “I don’t like that color.” Given a blank slate, some people won’t know exactly what you’re looking for in terms of the user experience design or data visualization style.

5. Avoid Disasters While Celebrating Success

There will always be little problems. Maybe your data request is missing a crucial detail. Maybe your favorite tool can’t handle all those records. Maybe a family emergency takes you away from the project for a while. Stuff happens—and sometimes it feels like Murphy’s Law.

But how can you prevent those little things from snowballing into a crisis? Here are some best practices:

• Go into every project with a plan for a minimum viable product as a backup.
• Speak up as soon as possible, even about the little things and how you plan to combat them.
• If you feel that problems are becoming systemic and not just an “out-of-my-hands” issue, address those feelings with a project manager right away.
• Get clear time estimates from builders up front and overestimate, just in case.
• Find ways to celebrate successes—even small ones—so that the team communication isn’t all focused on solving the latest problem or pushing the latest deadline. Someone at SRCCON suggested Friday afternoon show-and-tell sessions for people to present what they accomplished that week. This can help combat project fatigue.
• Encourage a culture that understands that pieces sometimes have to be sacrificed, where, even if the team is disappointed (or even pissed), they understand—and have been there, too.
• A week or two after publication, schedule a post-mortem meeting with all stakeholders to discuss what worked and what didn’t in an effort to prevent the same problems next time.

The importance of communication cannot be overstated—in fact, it feeds directly into every item on this list. It’s something simple that any workplace could improve upon, whether it’s two people talking to each other or 25.

Some of the other suggestions here will work in your newsroom, some won’t for various reasons. Rest assured, just discussing these problems can help stakeholders sit up and take notice—we’ve seen it in our own workplace in the past few months. Change doesn’t happen overnight, but each little step gets you closer.

Anything we missed? Let us know in the comments.

• Share on Twitter
• Share on Facebook