How to Answer “Tell me about a time you failed”

In my junior year I led a four-person team for a semester-long consulting project with a real local business as the client. I was so eager to impress that I said yes to every request the owner made, without checking scope against our timeline.

By midterm we were committed to roughly double what we could deliver. I had to sit down with the owner and admit we'd overpromised — we cut the project back to two deliverables, and while we did those two well, the final presentation included visibly broken promises. Our grade suffered, and worse, I'd burned my team's weekends getting even that far.

The lesson rewired how I take on work: scope is a commitment, not a courtesy. In my internship the next summer, when a manager added a big request mid-project, I priced it against the timeline in writing and offered a trade instead of a yes. He took the trade — and told me later he trusted me more because of it.

Two years ago I led a software rollout for about sixty internal users, and I made the classic mistake: I treated training as an afterthought. The tool was configured well, the data migrated cleanly — and adoption cratered anyway, because I'd budgeted one training session and no follow-up.

A month in, half the team had quietly reverted to the old spreadsheets, and leadership was questioning the whole investment. That was my failure, not the tool's: I'd planned a technical project when the hard part was a human one.

I rebuilt the rollout around people — short role-specific sessions, floor champions in each department, weekly office hours — and adoption recovered over the next quarter. Every implementation I've run since starts with a change-management plan before a technical one, and my last two rollouts hit their adoption targets in the first month. I needed that failure; I just wish I hadn't needed it publicly.