Have you ever joined a project that was far behind schedule, significantly over budget, or seemed like it wasn’t making forward progress? If you’re in the world of software, odds are you have at one time or another.

If you find yourself on a rescue mission, know that you’re not alone in the struggle. Rescue projects are some of the most difficult projects to join. They also have the potential to be some of the most rewarding or beneficial to your company.

In the next few paragraphs, I’ll be sharing four bits of advice to consider when trying to get the project ship from sinking. Ready to get that ship back sailing? Let’s do this!

Gather as much information as you can about the project

After joining, it will quickly become apparent that there is confusion and disagreement about where and how to begin fixing things, what needs to be changed, what is the shortest path to delivering value, and even understanding the scope of what needs to be done. So how should a person or team approach a rescue project?

Read any and all documentation the project has generated. Go through every page on any project website, public facing or internal. Talk to project members to gather documentation locations as projects typically have multiple locations where documentation is located. Even if the documentation is old and known to be out-of-date, it still provides good context on project history.

When gathering information, keep in mind that there may be content that conflicts. As technology professionals, we value consistency and order and it may be frustrating to read conflicting content, especially if it’s unclear which is correct and/or up-to-date. Or maybe none of it is up-to-date. But keep in mind that all information about the project will provide either current state, previous state, or context about how the project has progressed. All this information will almost certainly be valuable at some point. Consider the last time you were in a meeting and someone brought up something you didn’t know existed on your own project. That’s expected in the beginning, but the sooner you can get past that stage the faster you’ll be able to be a valuable project resource.

Assess

Whether you’re just joining the project or you’ve been on the project for a while, take a step back and do an assessment. What are the strengths and weaknesses? What needs to be changed to result in the project delivering value faster? Are there any documents you think would be helpful but don’t exist? Take your own ego out of the equation. If you were in your client’s shoes, what would you expect or need?

Even if you haven’t been asked to write an assessment document, create one anyway. Write up a background of the project to date, list the current state, list any future state vision, and enumerate the goals of the project. Then start listing the changes you would make and the reasoning. Pay close attention to staying objective when suggesting changes. After you’ve been on the project four to eight weeks and have a fairly mature assessment document, share it with your fellow project members and ask for feedback and/or corrections. It may start a discussion about what changes need to be made.

While writing the assessment document, keep a list of documentation that doesn’t exist (or you just didn’t find yet) that would have helped you understand the project better. List in the assessment recommendations to create this documentation, which may help not only current project members but the next new project member get up to speed faster.

Projects are People

When talking about a rescue project, I’ve heard it said that “tech is easy.” It doesn't mean that fixing technical issues is always easy, but rather that fixing technical issues is easier than fixing team issues. Projects are collections of people who work together to accomplish a goal. By definition, a rescue project usually consists of a team or team members that are not working as well together as they could to accomplish their goals.

Consider that, in small group communication, there are multiple phases the group must go through before it can work together effectively to accomplish goals. As new members join there will inevitably be a regression in the stages as new members assert themselves and the group adjusts to a different dynamic. Take this into consideration before making assumptions or assertions about past project members and roles.

If there is conflict then that means that not everyone agrees on what is best or the way to go about achieving shared goals, but don’t assume that project members are being difficult just for the sake of being difficult. At the end of the day, with very few exceptions, everyone is doing what they think is best for the project.

Change Takes Time

As motivated workers, we want to start fixing the project right away. We want to see our progress reflected in the timeline or the budget. We want to make a difference! But realistically change takes time. And the amount of time that takes has some relation to how long the project has been in existence. So don’t get discouraged when weeks or even months go by without seeing the change you think should happen, or even when you see what looks like a regression. Continue to work hard and put in your best effort. Often change comes suddenly and unexpectedly, so just when you think it’s never going to change may be right before you get surprised.

All Aboard

Rescue projects are some of the most challenging and rewarding projects one can be assigned. Whether you wanted to be assigned to the rescue project or not, approaching it with a positive attitude and coming prepared will lead to outcomes you can be proud of. And you never know, you just might help the project sail off into the sunset.