Case study—a project from hell

Published:

Project T is a project that I don’t want to remember. It was a big project for a big company—a project that I thought I would be proud to include in my portfolio; and boy, I was wrong.

Project T was bad. It lasted nine months when it was supposed to last three months. At the end, I gave a huge discount to the agency because they lost money on the project; as a result, I lost big time too.

Of the original team—a project manager, a visual designer, a UX designer and a frontend developer (me), I was the only member that survived the project till the end. Largely because of two reasons:

  1. I was stupid and naive
  2. My sense of responsibility didn’t allow me to abandon the project halfway.

By the end of the 9-month long project, I was burned out, and I quit freelancing for a year.

I bottled up my feelings for three years before writing this case study because I fear the case study would reflect badly on me—I only had negative experiences to share.

But I still want to share the lessons I learnt from Project T. While doing so, I want to keep the project, client, and agency anonymous to protect all parties.

To summarize, I learned three important lessons.

  1. There’s no client from hell
  2. Project managers need to shoulder 100% responsibility for the project.
  3. Design and development teams should talk from day 1

There’s no client from hell

Service providers love to blame clients for things that go wrong. It’s never our fault; always theirs; or so we hope.

For this project, things went immensely wrong. Let me give you a typical example:

  • Day 1: We proposed a solution to a problem they had
  • Day 3: They came back with a different solution. My project manager would accept their solution and we’d work on it.
  • Day 5: Feature completed
  • Day 7: Meeting held; they’d say the solution wasn’t good enough; they would like to propose another solution. This “new” solution was what we initially proposed. My project manager accepted again, and we’d get to building.
  • Day 9: Another meeting held; solution wasn’t good enough again; some other ideas needed to be explored. We went back to the drawing board.
  • Day 11: My project manager couldn’t translate the requirements, I’d pop into the meeting, discover that the previous solution was everything they needed, proceed to explain, and everyone agreed. We thought the case was closed.
  • Day 13: Something wasn’t good enough again. We had to go back to the drawing board. Rinse and repeat

And so, we spent a month, maybe more, designing a carousel.

Although there were politics and backside-covering messages flying around, they weren’t difficult to handle. If anyone was to take responsibility for what transpired, I believe the project managers should be the ones responsible.

So, there’s no clients from hell. There are only project managers who don’t perform.

Project managers need to shoulder 100% responsibility for the project.

Here’s a crazy thing you’ll never believe—my project manager’s view on the project was: “Just give them what they want”.

Can you imagine how much pain the development team had to endure because of this attitude?

If you can’t, imagine rebuilding a carousel 7 times throughout a project. (I forgot the actual number, but we rebuilt many components many times without valid reasons). The development team complained day in and day out; morale was low; all of us (sometimes even the project manager) worked for at least twelve hours everyday.

The worst part of the project was—I was under immense pressure to build and rebuild everything as the sole developer on the project (for many months). I felt I was the bottleneck. I couldn’t push for much in the project because I had no authority (even though I had ownership). This was what caused the burnout eventually.

On the client’s side, their project manager could not stand firm on any decision. He’d get swayed by other department heads after a meeting and tell us his proposed changes, even though things were agreed upon in the meeting!

When we proposed a change, the project manager would go: “let me talk to the CEO and see what he thinks”. As a result, we would wait.

Before this project, I assumed that project managers would assume complete ownership of a project. I was wrong and naive. “Let me talk to the CEO and see what he thinks” should have been a red flag; I should have gotten out of the project right away.

Why? If the project manager doesn’t have complete authority over the project, it implies they don’t have ownership. If they don’t have ownership, they defer responsibility. When nobody makes decisions, nothing gets done.

Project managers on both teams need to assume ownership of the project. If client’s project manager falters, it’s up to our team’s project manager to hold the fort.

If you are a one-person team, you need to hold the fort yourself. It’s part and parcel of development work.

Design and development teams should talk from day 1

7 months into the project, management was finally ready to integrate our design and frontend into the backend. It wasn’t because they were finally happy with the design (the team could have made tweaks forever); it was because we had to launch in two months. We had to integrate and run QA tests before it was too late.

It was already too late.

Integration is difficult. Bugs are inevitable. Don’t expect a backend developer to understand 100% of your code, even if you documented well. Sometimes, people miss out important details.

The result?

Tonnes of panic, lots of overtime. We eventually managed to launch on time, but I (and another developer we hired to help ease the panic) had to stay an extra month after launch to iron out all the bugs.

Wrapping up

I tried to keep this case study concise and only mention key learning points. If I said anymore, I’d probably go into a full three-day rant or something.

Like I said, writing this case study was difficult because I feared the negative perceptions people would have of me once I released it. To be honest, I still feel afraid. I don’t know if it’ll adversely affect my freelance or job-seeking opportunities down the road should I need a job.

But I still want to release this article, because I hope you would learn something from my experience.

Want to become a better Frontend Developer?

Don’t worry about where to start. I’ll send you a library of articles frontend developers have found useful!

  • 60+ CSS articles
  • 90+ JavaScript articles

I’ll also send you one article every week to help you improve your FED skills crazy fast!