Pinpointing Expectations

In my work as a front-end developer, I’ve come to realize that expectations, and how you handle them, are one of the most integral parts of a project. Expectations are tricky things, especially because we don’t talk about them very much.

Somehow, we always expect other people to just know what we’re thinking. Expectations have a tendency to shift and change, too. Sometimes during the course of a project, as you learn, research, and work, expectations change because of new knowledge gained while working. Other times an outside influence changes, say a competitor comes out with a new feature or product, which could cause the goals and expectations of your project to change as well.

Not talking about expectations causes a lot of headaches throughout a project. We aren’t mind readers, but clients and colleagues often expect us to be. Even when expectations aren’t articulated, there’s often frustration when you don’t meet them. This is why showing your work as often as possible and talking about it as you go can be a helpful way to make sure things are living up to expectations.

So how do we handle this? We have to try as hard as we can to draw out the expectations at the beginning, learning what’s expected so that we can be prepared to meet those goals. We also have to check in throughout the project to see if things have changed.

Recently, I was on a project that ran over by several months, dragging on longer than I and, I think, the client expected. I was getting a bit antsy. When would we wrap up? What was going on?

As a freelancer, my schedule is important and things that throw it out of whack are hard on me. Sticking up for myself isn’t always easy, but the client’s schedule changed over the course of the project and it was my job to figure out how to make the project end successfully. I did the email thing, I asked all the questions, and frankly, I pushed a bit. After several emails, and some explanations on both sides, things were sorted out in a way that worked for everyone.

This wasn’t a huge issue, but it could have grown larger if not acknowledged, talked about, and handled. Often it’s the small issues that can snowball into bigger ones down the road, so handling them early on saves everyone a lot of grief. Below, I go into more detail on how to get a handle on expectations early so issues either don’t come up, or they don’t blow up into something unmanageable.

Managing expectations

At the beginning of the project I ask for a detailed scope. The goal of this is to have everyone spell out what the end of the project looks like. When I’m done with my work, what will that work look like, what will the final project consist of? Ultimately, what is my deliverable?

If the scope of a project is tricky to define, I ask a lot of questions to get us there:

• What is the goal of the project?
• What do you hope I’ll have done at the end?
• How will we know it’s done?
• How often will we meet to discuss the project when it’s in process?
• Do you have a workflow you prefer for projects?
• Are there milestones along the way, midpoints in the project and what are they?
• What is the design process and how does the development team fit into that?
• How finalized do designs need to be before starting to work in code?
• Do you iterate and do designing in code or not?

These are questions I ask of my clients, but they can also be useful discussion starters when working on new projects within teams as well.

As a front-end developer, my final deliverable is often a template or page of a website, finished and ready for launch or integration. It could also be a report on ways to improve CSS for performance and maintainability, or a style guide and a cleaned-up codebase to show how the guide helped trim down the file sizes. Getting not only the final deliverable established, but also the process for getting there, helps everyone know not only what will be done, but how it will get done.

Since I write code, I also make sure I know about the coding standards for the shared repo. I want to make sure I write, test, and do anything else the client expects, so that my code conforms to their standards when the project is over.

When the expectations are unrealistic given the limits of code and timeline, I’m honest about limitations. We can do a lot with code, but we can’t do everything. Also, sometimes requests may be bad for accessibility or usability, so I’m not afraid to speak up and voice this to the team.

If the project is longer than a week or two, I try very hard to send updates, making sure I’m communicating where we are in regards to the expectations outlined in the scope and contract. Often, a regular call or video chat will do. Should I start to get the feeling that things have changed (you know, that awkward email exchange or tense video call), then it’s my job to ask about it. To have successful projects we have to be willing to have the hard conversations. Sometimes, a quick email asking if everything is OK is enough, other times it takes another phone call or two to sort through things.

I’m the first to admit it: some of this is hard. I sit at home in my office and worry at times. But whenever I’ve taken the bull by the horns and just asked what was going on, it’s always been worth it. Many times it proved to be something small, but other times it meant a course change for the project which saved time and effort on everyone’s part.

To avoid small issues snowballing or larger issues cropping up, have a good plan at the beginning of every project for how to handle expectations. You need to first establish what they are by asking a lot of questions, even the obvious ones, and then make sure you communicate frequently along the way. Hopefully things won’t change too much, but you’ll be ready to deal with them when they do.