How to Kill a Project

I’ve been working on a mobile project for the past 4 months. Last week I made the heart wrenching decision to finally pull the plug on it.

Killing this project hurt a lot. In the past 4 months, I had put in hundreds of hours. I even invested $10K from my own savings to try and bring it to fruition. As a full-time student with a six figure student loan, $10K is a HUGE amount of money to me. But I believed in this enough to give it a try. Unfortunately there were just too many obstacles remaining and it didn’t look like these problems were going to get resolved anytime soon.

A bit of background, the project was called AppRewarder (I’m not linking here on purpose because I don’t want any linkbacks from Google). The app was essentially a mobile exchange platform. AppRewarder would leverage several different ad networks to promote a list of apps. Smartphone users could log in and download a new app. I would receive a commission from the ad network by driving installs, and mobile users were incentivized to make the download because I would provide them with some type of reward.

Zombie Status

For the last two weeks I kept trying to push a little harder, thinking I was almost at the finish line. But no matter how much I worked, new problems kept cropping up that threatened to derail the entire project. After a particularly long and stressful day, I went up to the gym for a run to clear my head. And I had an epiphany – I realized that I needed to just cut my losses. The project was like a zombie, which is the worst kind of project to be a part of. It wouldn’t just die and allow me to move on; it showed just enough promise to entice me to keep chugging along, but it kept consuming my financial and mental resources. Eventually I felt like this thing was going to kill me with exhaustion.

Never Again

That night I lay in bed and couldn’t sleep. I kept thinking about all the mistakes I had made. I thought about all the time I wasted. The money lost. The more I thought about it, the more I realized that I never wanted to sustain a loss like this ever again. I had to figure out a systemic way to make sure a mistake of this magnitude never happened again.

I decided that I needed to hold a retrospective.

I first learned about retrospectives when I took my CodeAcademy class (now called The Starter League). It’s basically a debrief that software teams use to reflect on the wins and losses of a project, and to search for insights that might lead to team improvement. It’s part of the agile and continuous improvement mentality. I always thought this was a great idea, but for some reason never did one with my team. Maybe because things always seemed to be going pretty well that I didn’t think it was necessary. Big mistake #1.

My Janky Retrospective

I emailed my dev team and told them about the retrospective. They sounded pretty hesitant, I’m not sure if they had ever done one either. We set up a time to meet. My dev team is actually in Ukraine, so I had to stay up till 2am to talk to them.

I planned the retrospective using this format I found online

  • Purpose
  • Gather data
  • Generate insights
  • Decide what to do
  • Close the retrospective

However facilitating this type of conversation was way harder than I expected.

I opened by telling everyone the purpose of the meeting. The purpose was to reflect and gain insight about why the project failed to launch, despite the time we spent working on it. I gave them two data points. (1) We spent 548 hours on the project. (2) It was still missing the core feature.

I thought I was clear describing the purpose, but immediately the team started bringing up points about what features we still needed to work on. How we could still get it done. The conversation started going in a completely unexpected direction.

For example, one guy mentioned that they spent a lot of time communicating with API tech support, which was time consuming and difficult. Therefore in order to steer them into the direction of stating only facts, I borrowed a technique I learned from lean six sigma, and tried to ask 5 why’s, which is a technique to dig deeper.

“Why did we have to spend so much time communicating with API tech support?”

Well… we’re on different time zones, so scheduling is difficult.

“Why did they not respond to you? Because I usually got answers within 24 hours. Email problems? Permissioning problems?”

No they respond quickly, but our questions are unpredictable so you can’t really have a conversation by email.

“What actions can we take to improve this?”

(I realize these aren’t really why questions and I wasn’t able to get 5 deep).

Making Progress

Eventually the guys started to see where I was going with this and the ideas started flowing. To organize everyone’s suggestions, I followed the start/stop/continue format. What should we start doing (to improve), what should we stop doing (because it’s not working), and what we continue doing (keep doing the good things).

I asked them to come up with an actionable insight, and they concluded that the developer wasn’t the best person to handle this type of conversation. I have a PM that I work with who typically scopes out job requirements and allocates tasks, and his hours are not billed to the project. We decided that the PM would research these technical questions, and make sure we had all of the technical documentation regarding APIs, libraries etc. before the developer even saw any work.

In hindsight this solution seems obvious. But as someone in the trenches at the time, I can tell you that everybody on the team was backlogged with work and it was retarded easy to overlook a mistake like this.

We ended up talking for over 2 hours and generated an entire page full of insights that we could act upon. It was really uplifting to see the enthusiasm and hear everyone speak their mind by the end of the meeting.

To close out the meeting, I re-stated all big insights, and asked people to prioritize the top 2 actions that we had the time and energy to fix. After some discussion, we decided that (1) was communication, and (2) was project organization.

After this failure, I was pretty worried about getting burned again on future projects. But now for the first time in weeks I’m looking forward to my next big idea.

Leave a Reply

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