Ticker

6/recent/ticker-posts

Ad Code

Responsive Advertisement

Process Redesign: How We Rebuilt Our Most Vital Process in Under 20 Hours

process redesign

We rock process management and we are the first to back process redesign in a showdown. 

It’s even in our name. 

So how is it that our content team ended up using a crappily cobbled-together process for over nearly five years

And not just any process, mind you – the process of processes. The process we live and breathe by. The process that defines everything we do – including this very post. The one process to rule us all.

That’s right: Our blog production process sucked. Badly. 

We knew it, too. That was the worst part. The entire team was absolutely, painfully aware of exactly how broken and hodgepodge the blog production process (BPP) had gotten. 

But this came up and that came up – you know how it is. Improving the BPP became that thing that’s always on tomorrow’s to-do list. 

By the time we reached the breaking point, there were more exceptions to the process than rules – which is not a good process management system at all. 

So the question became: How do we redesign a process that is constantly in use without breaking the everything in the process?

This is how we did it.

Challenge: Our most essential process… broke

A diagram depicting a broken process design

“No one ever got fully trained on the old workflow. I spent most of my time following up on tasks that hadn’t been completed correctly – or hadn’t been completed at all – with people well past the onboarding stage.”

Leks Drakos, Content Editor

Broken processes don’t happen overnight. It’s a slow, incremental erosion that sneaks up on you. 

It’s always the little things that bite you in the ass.

But redesigning a process – even your most vital, can’t-be-taken-offline process – doesn’t have to be an apocalyptic event. With the right planning, tools, commitment, and – yes, I’m going to say it – Process Street, fixing broken processes can actually be kind of fun. 

The due date/publish date conundrum

It should be simple, right? A post is due on a particular date and it’s published on another (obviously later) date. 

Except that’s not how our process worked. 

In an earlier iteration, the only date entered was the due date. A trigger was created in Zapier to add the post to the calendar in the right place.

No problem.

Then we switched to entering the publish date in the workflow instead, which also shouldn’t have been a problem.

Except the original zap was never updated so the field for the publish date was still labeled “due date.” 

That was a problem. We needed a workaround.

Screenshot of an old version of the blog production process.

Foolproof.

Peer reviews, image requests, & Airtable

Blog posts need images. They also need to have peer reviews. The order this happens can be very important depending on how your process is structured.

“We had a review system that just didn’t work. The writers didn’t understand what they were supposed to do and even the editors didn’t know why they were using it.”

Oliver Peterson, Head of Marketing

Ours required the peer review task to be completed before the image request could be zapped to Airtable for the design team. 

This meant the design team often had to work under very tight deadlines with image requests coming in en masse right before publishing dates.

To get around that, we just zapped the image requests first and then verbally told the reviewer when the post was ready for peer review. 

And then the reviewer verbally told the writer when the peer review had been completed. 

No email reminders, no documentation in the workflow, no individual accountability. Just an assumption that each team member would remember to do everything they needed to do because they got a DM on Slack.

Foolproof.

Outdated policies & procedures

The old BPP had been around for about five years. There’d been some tweaks and adjustments in that time to be sure, but that really just amounted to stuffing unused tasks in the basement and hoping no one looked too closely. 

Even way back when I used the BPP for the first time, a lot of my “What is that?” questions were answered with “Oh, we don’t use that anymore.”

Fast forward a few years and I’m the one giving the very same answer to new writers. Except now there are even more policies and procedures we don’t use. 

It got to the point that during the onboarding process, I realized I’d told a new writer to skip more sections than to complete. Sections, not tasks. We were beyond merely skipping tasks. 

But even though those outdated procedures still hung around, it wasn’t a big deal because the rest of the team knew what they were and could give new team members a heads up if necessary. 

Because nothing has ever gone wrong when corners are cut. As long as we overcommunicate, it’s absolutely, 100%, totally foolproof.

Until it isn’t.

Solution: Reengineer the process… But when?

How do we rebuild a process that is constantly in use without breaking the entire system?

Yeah, we’re back to that question. Obviously, the process needed to be fixed, and equally so, it needed to be fixed sooner rather than later. Five years of putting something off is a long time, right? 

But the BPP is a process that gets used multiple times a day by multiple people. We couldn’t just take it offline and keep up productivity. 

We also couldn’t rebuild a live process in constant use without creating a tangle of confusion and bottlenecks.

“It was essential to follow our own advice. We needed a workflow that met the needs of both the newest team member and the most experienced. If we couldn’t do that, it wouldn’t be an effective process.”

Oliver Peterson

The Deming Cycle: Plan, Do, Study, Act

Process improvement tools are pretty neat really awesome. 

You know it’s true.

We really like the PDSA method. In fact, we have a small shrine devoted to Dr. Deming and Walter Shewhart (his mentor) in the Process Street lobby. 

Naturally, that’s the tool we turned to when it came to redesigning the blog production process. 

Well, that and Google Docs

A diagram of how to redesign a process using the PDSA cycle

First step: Plan. 

Oliver (Head of Marketing) and myself (Content Editor Extraordinaire) both created outlines of improvements we needed to make in the BPP to facilitate both SEO tasks (Oliver) and writing tasks (me). 

With the combined power of our mental prowess, we merged the two outlines into the Ultimate Blog Production Process. (For now.) 

“Before the process redesign, we just had this list of tasks that needed to be done to publish a post. It could be really daunting sometimes, but now with individual approvals and dynamic due dates for each milestone, it’s a lot easier to know if you’re on schedule or not.”

Grace Donaldson, Content Writer

We had our plan, but now what? There was still the problem of when – and how – to put this plan into action.

Time: 1 hour.

Second step: Do. 

Within the Process Street library, you can create separate folders to keep your various processes organized. 

One of the things we do is create a “sandbox” folder for each person at Process Street. This gives us space to play around with new processes, experiment with process improvements, and test out new features.

You can also duplicate any workflow in your organization in any folder you have access to. 

You can see where this is going, right?

We created a copy of the old BPP in my sandbox folder. Now, in the past, I’ve been pretty critical of Hammer and Champy’s reengineering concept – or rather their claim to developing it – but overall, it’s not such a bad tactic. 

To be honest, I’ve always been fond of the “trash and start from scratch” method. There’s just something really exhilarating about a blank slate. 

Plus, at this stage of the game, it was full process reengineering or nothing. 

Being the more impatient of the two of us, I decided this process would be redesigned and it would be redesigned now

I blocked out one full workday to go “offline” and – starting from a blank workflow – built the redesigned process. It actually took about a day and a half in the end to add all the instructions, images, cool GIFs, and special features but it was a day and a half well-spent. 

From that point, Oliver and I divided and conquered Automations and conditional logic, which meant we were ready for the next step.

Time: 12 hours.

Step three: Study. 

In a traditional PDSA cycle, this step happens in a safe sandbox where it can’t mess up any existing processes.

We sort of did that, except we didn’t do that at all. 

Once we made sure all the Automations and integrations worked, we made the redesigned BPP live for our writers, which meant they started using it at the start of the very next sprint. 

As a result, the entire team – along with our varying needs – was able to audit the process redesign and make sure all bases had been covered for everyone from start to finish, writer to design team.

“I wish I’d had this version for my onboarding. I spent at least an hour-long training session just trying to figure out the keyword research process – which also had a second workflow to use. Now everything I need to know is right here in one task. I love it.”

Grace Donaldson

Time:  3 hours.

Step four: Act. 

By the end of the sprint, we had a list of improvements to make to our process. The only thing left to do was implement those changes. 

And then start the cycle again.  

“Every time I redesign a process, I think: Why did I wait so long to do that? I could’ve had so much extra time if I’d just done it x amount of time ago.”

Leks Drakos

Time: 5 minutes.

Results: A process that works; a team that’s productive

I don’t know if you’ve been counting, but all-in-all it came out to 16 hours and 5 minutes for a beautifully redesigned process – with zero downtime for the team. 

In fact, they didn’t even know about it until the new version went live. 

“The new workflow is so much less intimidating than before.”

Grace Donaldson
A diagram of Process Street's redesigned content creation process

We merged 3 separate workflows and still reduce the number of tasks by nearly 75%. With one workflow alone containing more than 120 tasks, that in itself would have made the process redesign totally worth it.

But we also: 

  • Removed redundant reviews and included clear instructions for the remaining ones.
  • Reordered tasks into a more linear and logical flow.
  • Quality control checks when the writers and designers actually need them.
  • Increased efficiency and reduced bottlenecks by 98%.
  • Created a happier, more productive team that actually got to enjoy their jobs again.

“Sometimes you can be in such a rush to complete these tasks and get to the writing part that things get lost, but this new system makes sure that doesn’t happen.”

Grace Donaldon

The result is a more efficient, streamlined process that our team is able to use without making those mistakes that happen when a process only lives in your head.

It also means that bottlenecks don’t happen when the one person who knows exactly how to do something is busy or out of the office because we have clear process documentation. 

Clear documentation improves knowledge spread which increases transparency and allows your team to work at their full potential. 

When you don’t have a standardized process, you aren’t able to standardize your results. Over time, you end up with slight deviations in how people do things. Eventually, those deviations become normalized. Once that happens, any hope of consistent and reliable results is totally out the window. 

Get a free Process Street account and take control of your workflows today
No credit card required

Future: Continuous assessment & improvement

“It’s weird having enough time to do my actual job.”

Leks Drakos

A while back, a colleague at another company and I were gossiping about processes. Yes, we seriously do that. 

His company had standardized processes – and good ones, from what he described – but no one used them consistently. Some employees followed the processes religiously. Some didn’t even know those processes existed. Some still used outdated processes and some didn’t use any processes at all.

My colleague was one of the latter and I have to admit I questioned our entire friendship in that moment.

When I asked why, he shrugged and said, “It’s worked so far.”

So far.

Those two little words are just about as dangerous to your company as the word yet

You’ve managed to get by with a broken process so far. You haven’t needed to redesign your process yet.

But you will. 

You can either be proactive about your process redesign or you can keep putting it off until your system does crash. 

Trust me: Process redesign is a lot easier.

“The team doesn’t need me to tell them what to do; they know. Using things like approvals and dynamic due dates lets me stay involved in their progress without getting in their way. I’m able to support them more and support them better.

Oliver Peterson

What are your process redesign obstacles? Any tips and tricks? Let’s talk about it in the comments!

The post Process Redesign: How We Rebuilt Our Most Vital Process in Under 20 Hours first appeared on Process Street | Checklist, Workflow and SOP Software.

Enregistrer un commentaire

0 Commentaires