Life After Death (of a Project)

After my team spent a significant amount of time working on a project, it got halted. Ouch.

It kinda sucked, but it also gave us an opportunity to start anew. We could put the baggage of our old project behind us and start our new project with a clean slate. As a leader, you must recognize that emotions (including your own) must be considered before the team can effectively move on to their next project. We’re only human.

Here’s a plan for handling a mothballed project with your team:

  1. Communicate: what happened and what’s next.
  2. Recognize and recover from burnout.
  3. Do a project retrospective to learn from past project mistakes.
  4. Share the retrospective findings.
  5. Start the next project with a clean slate.

1. Communicate: what happened and what’s next

Biggest problem with communication is illusion it has taken placePublilius Syrus (a Latin writer who died in 29 BC) wrote, “Anyone can hold the helm when the sea is calm.” When there’s uncertainty about the future, team members look to their leader for guidance. As quickly as possible, let your team know what’s happening and what your next steps are.

First, explain what happened with your project to your team. For our project, my boss offered to share the news of the project shift with my team and explain the business reasons behind the change. I took him up on his offer. His talk to the team helped immensely, as it provided them with some context about the reasons for the change.

Next, explain to your team how you’ll move forward. After my boss explained the business changes, I shared with the team the specific actions we were going to take to move on. We had to wrap up our existing project work. But, to move forward, I felt we also needed to deal with burnout to start the next project refreshed, do a project retrospective to learn from past mistakes, and start our next project with a clean slate.

I verbally told my team our plan, then I followed it up with an email recapping it. Communication: BOOM!

2. Recognize and recover from burnout


Burnout is a dangerous thing. It sneaks up on you, and it won’t go away if you don’t make a change.

We’d been working on our project for a while. There were twists and turns and project changes along the way. We all adapted to these changes and continued working. Unfortunately, I didn’t heed the warning signs I saw in myself to prevent burnout. I kept on pushing through and drove headfirst into that Burnout wall.

With this latest change in our project, I wanted to make sure my team wasn’t feeling the same way. I sent them an article on preventing burnout. I acknowledged that I was feeling burnt out and was going to take a Friday vacation day off to recharge over a three-day weekend. And, I encouraged anyone feeling the same way to do the same.

My Friday off had no firm plans. I left the house in the morning, took myself out to lunch, saw a midday movie…basically filled my day with fun and relaxation. I benefitted immensely from it. I came back Monday happy and recharged. I only regret that I didn’t do this sooner. (I should have heeded my own advice in my blog post “Mood is contagious. Which one are you spreading?” by being aware of the bad mood I was demonstrating to my team by not dealing with feeling burnt out.)

3. Do a project retrospective to learn from past project mistakes

What happened on this project?One of the software developers on the team suggested this great idea: have a team discussion about the various ups and downs on the project. Figure out what happened with this project and why. A project retrospective!

Even though our project went through some changes in direction over the last several months, we never took time as a team to stop and examine what was going on. With the project halted, it made perfect sense to reflect on what went well, what didn’t, and what lessons we learned. I didn’t want us to ignore the same warning signs on our next project.

Our team ScrumMaster facilitated the project retrospective. We deliberately did not include upper management in this discussion to help ensure people would speak openly and honestly. (I did intend to share our observations with my boss, though. I let the team know before our discussion that I’d be summarizing our observations and sharing them, but that I’d let them know exactly what I was sharing.)

To let people get their frustrations out, we set a timer for 10 minutes at the beginning and let people vent about what bothered them on the project. After the timer expired, we would dive into what went well and think of action items. Beyond venting, we had to figure out how to fix what didn’t work and keep doing what worked well.

We had a great discussion of the pain points on the project and came up with several action items that we could implement ourselves to make our next project better. We actually were able to turn the 10 minute “venting timer” off early because our conversation naturally flowed into “what are we going to do about it?”¬†territory.

I wrote down notes of our discussion and our action items. Even for things outside our span of control, we were able to identify some “red flags” that we could be mindful of on the next project. If we saw any of those again, we would take action by escalating our concerns to our superiors.

4. Share the retrospective findings

After our project retrospective, our ScrumMaster observed the team comments could mostly be sorted into two main issues. I wrote up a summary document with these two main points as headers and provided examples from our retrospective that supported them. I also listed all our team action items and who was responsible for each improvement.

I sent this list to the team with a 24 hour review period to make sure I accurately captured what we discussed. I advised them I was going to send it to my boss, and asked for feedback on anything they objected to me sharing. The team was OK with everything, so I sent it to my boss with a copy to my entire team.

My boss now knew our perspective on the good and bad during the course of our project. More importantly, he knew exactly what we were doing at our team level to make our next project better. Even though some decisions on the next project would again be out of our control, we would do what was within our control to make it go as well as possible.

5. Start the next project with a clean slate

I feel the start of something new.I saw tremendous value in discussing the rights and wrongs of our halted project. In a lot of ways, it was a team therapy session.

Importantly, we didn’t overly dwell on complaining. While we started off venting, we quickly started coming up with action items we could do to prevent the same issues on our next project.

My intention was for us to let go of our old project’s baggage and start the new project fresh. With our published list of action items from our retrospective, everybody knew who was doing what to make our next project run better.

These steps all helped us start our new project with a clean slate. I plan to do a follow-up on our action items a few weeks into our new project to ensure everyone is doing what they committed to. Although we can’t guarantee that everything will go smoothly on our next project, we can make sure what we control works better for us than it did on our last project. Never stop improving!

One thought on “Life After Death (of a Project)

  • July 27, 2015 at 9:45 am

    Wow, thanks for sharing this. Having been a part of the team you’ve built, it’s a great read. Well done.


Leave a Reply

Your email address will not be published. Required fields are marked *