Newsrooms are living in uncertain times. While it is clear that the old way of producing and presenting journalism isn’t well-suited to the digital age, experiments have yet to coalesce into new structures or newsroom cultures. In the course of managing this change, a lot of focus has been placed on the technologies, business models, or skills needed to do good digital journalism.

Much less discussed is how workflows and processes need to change, and how newsrooms can create new ways of working—which is why, as of today, we are publicly releasing our IKEA-inspired toolkit for running newsroom projects.

At the Financial Times, we believe the key to fostering innovation and collaboration lies in having small, well-managed, multi-disciplinary teams pursue projects alongside our existing production line of news. By projects, we mean: any journalism that can only be done by bringing together an ad-hoc team across desks.

But to most reporters and editors, project management processes on collaborative projects can feel both alien and inefficient: “You want me to sit here and think about what success looks like, when we could just get on with it and get the story done?” At a time when resources are thin and everybody is overworked, even things like defining goals, writing down plans, and making sure everyone is informed can seem ancillary to “getting the story done.”

Yet, how many graphics desks have turned down last-minute requests for interactive news apps to go with projects that were already weeks or months in the making? How many reporters have felt like they had been jerked around with conflicting messages by editors or producers who were all working on the same project, and yet have clearly not bothered to speak to each other? How many editors have become disillusioned with audience analytics after receiving lots data but little insight?

These are all symptoms of poor project management. As special projects editor at the Financial Times, I’ve been trying to introduce project management skills into the newsroom in a way that’s useful to reporter and editors. My hope is that by doing so we can produce better journalism, create room for experimentation, and learn from our experiences.

I started doing this by working directly with editors and reporters on their projects—which ranged from reporting series, to innovative digital storytelling, to coverage of big news like Brexit. That approach yielded incredibly useful insights, but was ultimately limited in scale by my time and availability.

So with the help of designer Caroline Nevitt, we created the Financial Times special projects toolkit—a set of resources and documentation of best practices that anyone can access. It is intended to provide all the information an editor would need to know to successfully manage an editorial project.

We are releasing this publicly on the Financial Times’ GitHub account for two reasons:

1. Every newsroom faces the difficult challenge of making cultural and workflow changes, but there isn’t a lot of discussion about the specifics of how different organizations are tackling this. We hope to spark these conversations by being open and transparent about what we are doing.

2. While the specifics of the toolkit can’t be directly applied to other newsrooms, we’re hoping its design and the thinking behind it would be useful for other newsrooms attempting to create similar change. In turn, their feedback and experiences will help us refine and improve our toolkit.

In this article, I will explain the design choices we made, what we wish we had done differently, and what unresolved questions remain, when it comes to project planning in newsrooms.

What Is It?

The toolkit contains six modules. Each module address a specific question that arises in newsroom projects:

1. What projects are already in progress?—An online calendar showing current projects
2. How do I get started?—A form with questions to help hone project pitches
3. Who do I talk to about…?—A concise contact list of key project personnel
4. What do I do if I’m put in charge of a project?—A detailed production checklist for editors
5. How did my project do?—An analytics template that serves as a starting point for discussion between editors and data analysts
6. Review meetings—Instructions for how to conduct them

The modules work independently of each other—and taken together, they work like instructions for assembling IKEA furniture, giving editors a framework and all the information they need in order to smoothly run a project.

The toolkit comes as a PDF because it is specifically designed as a paper product. It is meant to be printed out and scribbled on: Editors can sit with reporters to write down the answer to questions in Module 2 directly on the page as they discuss a potential project. They can cross out completed tasks in Module 4, or annotate the checklist with their own notes.

The toolkit isn’t panacea. It probably only takes us about 20 percent of the way towards creating the change we want. The other 80 percent is the work that happens quietly in the background: consistent and continuous effort to help editors run projects, through one-on-one partnerships, internal classes, structural changes, and so on. But it’s a start.

The Thinking Behind It

In designing the toolkit, we had to solve several design problems. The biggest challenge is one that is common to all toolmaking: no two projects are exactly alike. We were designing one set of resources for a range of different situations and levels of expertise.

This was an issue because we believe the value of the toolkit lies in the very FT-specific details about who to talk to and what needed to be done. Too much abstraction and generalization and we would lose that value. But being as detailed as possible risked making the toolkit overwhelmingly dense and difficult to use.

The breakthrough came when we realized that, instead of creating a single tool that solves one big problem (How do I run a successful project?), we could break the problem up into smaller parts and design specific, independent solutions for them. And so the idea of making it modular was born.

This also allows us to easily adapt the toolkit as best practices evolve—we can always add or remove modules as necessary.

The second big challenge is “discoverability.” Most editors will only run projects very occasionally, so they will not need to use the toolkit most of the time: how can we make sure they can find it when they do need it?

Simply having it exist somewhere online is not good enough. I learned this the hard way with Module 1, an online calendar of ongoing projects that anyone within the Financial Times newsroom could, in theory, consult. While it was clearly useful to many of my colleagues (they kept asking me for the link), it was also clearly hard to find (they kept asking me for the link).

One imperfect but simple solution was to make the toolkit a primarily print product that could be placed on people’s desks. People are more likely to use something they can hold, rather than something they’ve bookmarked—an insight I owe to Eric Athas, who managed NPR Training and is now at the New York Times. It also means that the toolkit can be printed out and used by digital specialists like our Audience Engagement or graphics teams, to lend structure and authority in their discussions with editors or reporters.

There are other advantages to eschewing digital interactivity for a static, printed design: we didn’t have to think about potentially thorny issues such as responsive design for mobile, access control, data storage, and so on.

What We Learned

One of the most important lessons was realizing that I was creating a tool to solve other people’s problems. At first, I just wrote down my process for running projects and gathered together material that I found useful, naively thinking that others had similar issues.

It was only through talking to reporter and editors, working alongside editors running projects for the first time, and going back to desk-editing for a short stint that I was able to re-focus the toolkit around the problems all of its users actually faced. For example, Module 3, a simple contact list of people likely to be needed in projects, addressed a problem I no longer had, but which was a common complaint among reporters and editors: “I don’t even know who I would talk to about that…”

Even so, we could have done more user testing and iteration. We did some, and the modular design of the toolkit already makes it easier to test, but as we launch this internally within the Financial Times, I’m still noticing things to improve upon by observing how people are (or aren’t) using it.

Another lesson is that design matters, a lot. Design doesn’t just help solve the practical issues of making information easy to find and understand. Much more importantly, it can help overcome a major hurdle that such initiatives face: Most people instinctively recoil at the thought of having to consult manuals, follow checklists, or fill out forms. Caroline Nevitt’s design helps ensure that when people first see the toolkit, they don’t think that they are looking at a corporate training manual.

Questions to Consider

If you are interested in introducing something similar in your newsrooms, it’s worth considering the following:

• Does this size fit you? The toolkit is most useful when your newsroom is doing too many projects for a specialist project manager to give individual attention to each of them, but few enough that it’s not already embedded in the structure and workflow of the entire newsroom. (i.e. too many for one person, too few for a new department)

• Are these your problems? Some modules might be more useful than others. You might need completely new modules.

• “Why” and “Who” always matter more than “How” and “What.” Detailing what to do and how to do it is not particularly useful without knowing who will do it and why they should do it.

In the meantime, the whole project is up in our repo, so please dive in.

• Share on Twitter
• Share on Facebook