When a Project Goes Sideways: What I Do and What I Say
If you have ever hired someone to build something for you, you probably know the fear. Not that something will go wrong, but that it will go wrong and nobody will tell you. The updates get vague. The replies get slower. You find out how bad it is when it's too late to do much about it.
I don't want anyone to feel that way while working with me. Things do go sideways sometimes. That's the nature of building anything real with real people. What matters is what happens next. Here is what I do and what I say.
I tell you plainly, and I tell you early
The moment I know something is off, you will know too. I won't wait for a tidy answer first, and I won't hope it sorts itself out by Friday.
Waiting feels kinder, but it isn't. Bad news doesn't get better with age. It gets more expensive, and it takes away your chance to make choices while you still have good ones. If a deadline is at risk, I'd rather you hear it from me the same day than discover it at the deadline.
So the first message is short and direct. It says something has gone wrong, roughly how big I think it is, and that I will follow up with more as soon as I have it.
I explain what happened in everyday words
You shouldn't need to know how the software works to understand what went wrong. If I can't explain it in plain language, I haven't understood it well enough myself.
When I explain, I try to cover four things:
- What happened, in a sentence or two.
- What it means for you and the people who use what we're building.
- Why it happened, as far as I know. If I don't know yet, I say so.
- Whether any of it was my doing. If it was, I say that plainly. No hiding behind technical talk.
That last one matters. Sometimes the cause is a mistake of mine. Sometimes it's a surprise nobody could have seen, or a change of plan along the way. I would rather be honest about which it is than make it sound like less than it was.
We agree on the next step together
I don't show up with a problem and a decision already made. It's your project, and your people, your members, or your congregation are the ones who live with the result.
So I lay out the real options. Usually there are two or three: fix it now, adjust the plan, or pause and rethink. I tell you what each one costs in time and effort, and which one I'd pick and why. Then we choose together.
For a business or team, that might mean trading a feature for a date, or moving a date to protect quality. For a church or ministry, it often means thinking about the people first: a Sunday launch, an event, or a volunteer team who needs something that works. The right answer depends on them, and you know them better than I do.
Then I keep you in the loop until it's fixed
One message isn't enough. After we agree on the next step, I keep checking in, even when the news is "no change yet." Silence is where worry grows, so I'd rather say a small thing than leave a gap.
When it's resolved, I tell you that too, and I talk about what we can change so it's less likely to happen again. That might be a clearer plan, a check earlier on, or a better way of handing work back and forth.
Why I work this way
I've been solving problems with software since 2007, alongside universities, hospitals, household-name brands, nonprofits, churches and small businesses. I've also built products of my own. Across all of it, one thing holds up: trust isn't built by projects that never go wrong. It's built by how the hard moments are handled.
If you'd like to know more about how I think, you can read about me, see the products I build, or read more in my writing.
I take on a small number of outside projects each year, so I can give each one proper attention, and so I always have time to tell you when something needs saying.