The A List Apart Blog Presents:

Pinpointing Expectations

Article Continues Below

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.

About the Author

Susan Robertson

Susan Robertson is a front end developer working with Fictive Kin who focuses on CSS, style guides, responsive, and accessibility. In the past, she has worked with clients such as FiftyThree, Imprint, Cloud Four, and worked for Editorially, The Nerdery, and Cambia Health. When not actually writing code, she can be found writing about a wide variety of topics on her own site as well as contributing to A List Apart and The Pastry Box. When not staring at a screen, she reads comics and novels, cooks lots of yummy food, and enjoys her Portland neighborhood.

13 Reader Comments

  1. Yes, I have something to say. Susan Robertson, I don’t know you personally, but I’ve got to say you write such good articles. LIke last time, I’ll be tweeting this.

  2. Another great article. Well done, Susan!

    I have a question: how do you handle agile projects?

    Most of the time, freelancers talk about close scoped projects. Is it just not normal to a freelancer to do agile work?

  3. You nailed it Susan! Managing expectations it’s so crucial for the success of a project. Working in design agencies, I often saw sales over-promising or setting wrong expectations about a project, jeopardising everything from the beginning. The best remedy for this is to include the client along the process, and – as you said– to show your work as often as possible.

  4. @Hugo I would say that I handle Agile in much the same way. I don’t just work in a waterfall fashion, in fact I’m starting a project right now that the designs are kind of getting there, but we are starting with the base things and refining from there. I don’t think it’s any different, really, at the end of the project I’m still delivering the same things, we are just getting to the end differently. I hope that makes sense. Also, when you paid for your time rather than a fixed bid, it makes it easier to iterate and most of my project are time based, not project based when it comes to how I’m paid.

  5. Great set of questions, Susan. I can see that the answers to the questions will help create a price. It is worth discussing these prior to the contract agreement. I would try to educate the client on how their answers will adjust the price.

  6. Thank you Thank you Thank you. I would even say that expectations are the “most” important part of a project. When you nail down expectations, everything else comes along relatively easily.

  7. This article is really relevant for me at the moment, I have currently been working solo and now will join a team of developers. I kind of got launched into the middle of projects without even seeing a brief or anything and expected to get the job done. It was incredibly stressful at times.

    Now we have some resource the developer team have all sat down together and started to manage expectations with things like a functional spec. Expectations are probably one of the hardest parts of being a developer, in my opinion, technical challenges are just fun and interesting.

  8. Managing expectations is one of the best things you can do when working with clients on a project. It takes a while to get the hang of it but it makes everything go so much smoother once you’ve perfected it.

    Great set of questions though and I’ll definitely adapting one or two to use in my own set I send to clients.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA