The Three Rs: A Framework for Handling Problems in Projects

Sometimes Murphy’s Law takes over and things don’t go according to plan; taxonomy projects are no exception. Following best practices, using available documentation, and good modeling can help avoid pitfalls, but they provide no guarantee that problems won’t crop up at some point. Knowing that we’re always in danger of unexpected issues, it’s important to be able to get past them and get the project done.

Over time I’ve come up with something of a personal framework to help handle setbacks and unforeseen issues. I’ve found it useful because it emphasizes learning and adapting, and practicing resilience. I’m sharing this framework with others, just in case it helps someone else who’s in a jam.?

I call my framework the Three Rs. Each R represents a different phase in the process of recovering from a project setback. It’s broadly applicable to projects of any size, and can be used as an iterative process.

The Three Rs are: Review, Regroup, and Retry.?

Review

Goal: Learn what went wrong and what options are available for mitigating or avoiding the issue when the time comes to try again.

Possible Tasks: Going through error logs, reviewing documentation, updating or rechecking a model, working with technical teams.??

It’s a great idea to develop documentation based on what you learn, because it’s an opportunity to learn and to create a useful reference for others.

Outcomes:?

1. At the end of the Review phase, you should understand what the problem was and have a suggestion of how it can be avoided in the future.

Regroup

Goal: Communicate with stakeholders and create an updated project plan that will complete the project in a way that deals with the problem.

Possible Tasks: Talking with stakeholders about what the issue was, how we plan to deal with it, and discussing our changes to the plan. Working with other teams to update the project plan, such as getting on a technical team roadmap, requesting database resources, or creating a retagging plan for content owners.

Outcomes:

1. The project plan is updated and stakeholders are aware of the updated plan and timeline.

Retry

Goal: Execute the project following the updated plan that we communicated to stakeholders in the Regroup phase

Possible Tasks: Any tasks required by the project plan itself, notifying stakeholders that the issue has been dealt with, updating project tracking systems.

Outcomes:

1. The problem is now taken care of and the project can continue.?
2. If another issue arises, then go back to Review with it.

Earlier I wrote that this framework is broadly applicable to a range of project sizes. I offer that from personal experience, because the actions I take when a problem arises are more or less the same regardless of the project size. A larger project might be much more complicated and have many more moving parts, but I was still doing the same things I did for those small, everyday tasks when the unexpected happened.

Here’s how the framework might manifest during a small, everyday task. For example, I’m doing a minor update to a taxonomy in the taxonomy management system using an import file. I try to make the update, but the system doesn’t accept it and spits back an error message.

Review: I look at the error message and at the update file and I realize that one of the columns in the file is formatted wrong.

Regroup: Correct the formatting in the column. If I have someone waiting for the update, I will shoot a quick message,apologize for the wait, and let them know I had to fix something in the update file.

Retry: Reimport the file, make sure it imported correctly, and inform the stakeholder that the update is completed.

Since this framework is coming out of my experiences, it’s totally possible you’re doing something like this already. If you are, please share your variations! What do you do similarly or differently? I’d love to learn more.?

#factorfriday #informationarchitecture #bestpractices