Managing Client Expectations

A couple of months into my apprenticeship, my mentor started scheduling regular Iteration Planning Meetings (IPMs). After assigning a project, we have these IPMs every week. During these meetings, we define user stories that I will later scope out for approval and finally work on in order to complete the project. These meetings have really helped me with planning the project and setting deliverable expectations. My mentors play the role of clients for these meetings. Consequently, I’ve been learning quite a bit about my communication style, evaluating where my communication breaks down, and improving my communication with my mentors so that I’m more prepared to contribute on billed projects.

And when I say that I’ve learned a bit, I mean that I’ve been messing up and learning the hard way. The goal with any project is to walk away with a great relationship with the client and stellar project. I’m going to share some tips that I think will spare some tears when interacting with clients.

1. Establish regular communication and reminders to maintain regular communication.

My mentors and I meet every Friday for project demos. I’ve made the mistake of forgetting to create calendar events and send invites for meetings. Sometimes I thought I sent out invites, but then I saw something shiny and realized at the moment that I got side-tracked and never created the meeting. Establish your schedule in advance and send invites for at least as long as you think the project will be. And if you do need to set invites weekly, use a reminder tool so that you don’t forget to create events. I use Slack’s “remind me” tool — it turns out that I forget a lot of important things without it.

2. Be transparent about your progress

While working on user stories, send regular updates, especially if something is taking longer than anticipated or if you’re stuck somewhere. The key to a great relationship (besides working code) is no surprises. Do not surprise the client with good news or bad news. Keep them apprised on the progress. Sometimes deadlines will need to be pushed back. Especially as a new developer, I don’t know how long things can or should take. That kind of information will come with experience. What does not have to come with experience is being upfront as you learn about sudden unplanned dependencies or as you learn that features will take longer.

3. During IPMs, set clear deliverables

Set clear deliverables by breaking down user stories. Breaking down stories comes with experience, but I’ve already been noticing that I push back when a story doesn’t seem to have a single responsibility. Use Trello or similar tool to make checklists that cover the experience and the developer tools needed to meet those requirements. Don’t be afraid to put deadlines on the cards and store them in your calendar to keep you on track. Most importantly, if you say that you will deliver a card, you need to deliver that card or communicate as soon as you know that you won’t be able to deliver it. My favorite saying from one of my mentors is "Under promise, over deliver". Promise to deliver only what you know you can absolutely deliever and then anything delievered beyond that is a bonus. I now have a “day before demo day” deadline to report if something will not be complete by demo time so that everyone is on the same page before demoing. I also come up with an action plan along with a due date to address the feature.

Along with setting clear deliverables, avoid the temptation of modifying established deliverables. Key word there is “established”. If you deliver something that has been agreed upon and after seeing that, the client wants to add a related feature or change the delivered feature, that should not be taken as a problem to solve right away. Instead, treat that as an invitation to have a conversation about these new details and requests. There has to be room for a conversation to discuss those new items because you don’t yet have all of the information that you need from the client and the new request will require time to complete. So if I’m asked to deliver something that was not part of the original project scope, I make it clear that the overall project deadline will probably need to be adjusted to allow for the new feature. The time that it takes depends on the feature, but there still needs to be a conversation so that everyone is on the same page.

4. Plan for the unknowns (literally)

You’re probably not going to know all the details of what you’re being asked to do even after clarification. I didn’t know about functional programming up until a couple of months ago, yet my requirements called for a functional programming language. I try to identify unknowns and plan for them. And when I say plan, I mean actually plan. About how much time will you need to spend on learning a new tool or language? How much do you need to know to meet requirements or solve certain problems? One of my user story cards at the beginning of my current project was a learning spike. I made it clear to my mentors that I would not be able to produce anything tangible for two weeks since I was learning a new language and paradigm.

5. During IPMs, be honest by setting realistic expectations

Last week I made the mistake of committing to several cards on top of being out of the office for a conference. This by no means was realistic even with the normal occurrence of miracles. I felt a personal pressure of wanting to finish my project on top of thinking I could solve a particular problem in a still just slightly familiar paradigm. It was an unhealthy and unrealistic expectations and I had to explain my shortcomings and come up with an action plan. It’s not a pretty situation. So be honest with yourself. Come up with an honest plan even if it means that you’ll take longer on a project. And make that plan clear to your client.

I hope these tips will help you master client interactions, afterall 90% (or more?) of software development is communication.