Managing Expectations

I built a low retaining wall as a small side project for a friend of a friend. It extend her parking area and also to created a little entertaining space. It was a small project that I fortunately kept fairly self-contained – I say fortunately because as we started talking about outdoor tables and string lights and bringing drinks up from the kitchen, I could see how over a longer period of time the project would have crept into something more complicated, and harder to manage.

It's not that the project itself would get too complicated, it's about managing client expectations.

Working with clients in any capacity is always more about managing expectations than dealing with the actual execution of the project – clients get ideas in their heads, and if you've done enough projects you know these arguments because you've heard them before. It always feels like a waste of time to have these discussions but it's just part of the job to navigate the expectation and help the client understand the problems and keep the project moving.

But there is something that makes managing expectations even harder to manage: Google.

Every project has its problems. Everyone wants to solve those problems. We solve those problems by looking for answers. And we look for answers by Googling.

Neil DeGrasse Tyson has pointed out that there is nothing that supports your confirmation bias more than a search engine. You're not just looking for answers, you're looking for answers with a predefined idea, and you tend to shape your search to find what you already think the answer is. And when you find something that supports your idea, you say, 'Ah, there it is.'

No one really takes the time to then search to see if there are opposing views to that answer or what might be wrong with it.

And once you've found what you're looking for, you get a touch of the Dunning–Kruger effect, that is, you have learned just a little bit about the topic, but you feel like you know a LOT.

Part of the problem is YouTube. Don't get me wrong, I look up how-to videos all the time on YouTube. But when we watch someone do something in a video, we sort of feel like we've actually done it too. There is a visceral connection to that one project on the screen that makes us want to believe it's as easy as all that – after all we know it works because we SAW it.

We forget that there's a lot of editing, we don't really know the level of effort that went into the project in the final video. And we rarely know know the level of skill someone has, or if this is the best or only way to solve the problem, or honestly if it really does solve the problem for the circumstances in our own project.

All this stuff we see on Youtube, Pinterest, blogs, Facebook pages… all the social sharing gives ideas and glimpses, and while I think they are great for research, you have to put them in the fantasy category. They can give you the ideas, but the actual plan still needs to be figured out and you should have some level of experience to understand what it's really going to cost in time and effort to pursue that idea.

The challenge I have when doing work for other people isn't just establishing my own credibility for the project, but I have to fight off mid-project requests that start with 'I was watching this YouTube video and this guy did it totally differently than how you're doing it.' I have to balance my own time against a 2-minute, nicely edited video that results in something that, at least on the screen is absolutely fabulous, where my real-world project might be half-way done and showing flaws.

When it comes to those flaws, which all projects have, I talk about a 'reasonable level of disrepair.' Everything we use in the world has some flaws, and we're usually okay with that. Our roads can be a little rough, for example, but they can't have potholes that break cars. Where we get in fights is surprisingly not about fixing potholes, but the definition of 'a little rough.'

That level of perfection, or that acceptable level of disrepair, is very subjective. It's that subjectivity that shifts from the beginning to the end of project. My client may not know that they are upping their standards as they learn more about what's possible while trying to help with what may have gone wrong during the project.

This is why I always try to run a project with one simple thing, something so basic that we all actually skip it far too often.

You need a plan.

Blueprints, design specifications, charters, or whatever your industry or team calls it, you need to be very explicit in what the goals are, what the minimal viable product is and what the expected outcome is, which is always a higher standard than the minimal viable product.

Then you can, and should, reference that plan. Document any time you change the plan, and you can totally change it. I've always said, 'we make rules so we know when we're breaking them.' Sometimes the change saves time and money, sometimes it costs more. Sometimes it doesn't seem like it has any impact until you get further down the road and find that the accepted change was kind of a bad idea.

Which gets me back to my first comment – I like small, self-contained projects because it's harder for them to go sideways. And of course, they DO go sideways. I mean, I did hit a water line with rebar on my little retaining wall project.

And that wasn't a time to look it up on YouTube – that was a time to get a plumber, because there is nothing like water spewing out of the ground to set a new level of expectation.