Managing Client Expectations
This is something that I have been wanting to write about for some time. For one reason or another I always fail to do so. Often it’s because I have that little guy on my shoulder telling me that if read by the wrong person it could be interpretated incorrectly and it could have negative impacts on me personally or professionally. Well that being said, the hell with it…:)
I’ll focus this specifically to managing expectations on projects. Now note that managing expectations shoud be something you strive and work towards in everyday things, from sexual relationshiops to professional ones. I’ll write about the sexual ones later…
Since we’re talking about expectations, I don’t plan to introduce anything you probably don’t know already or something that is earth shattering but it might surprise you when you see it written down. I will also focus specifically on managing client expectations, specifically in the IT/IS industry. Allowing expectations to become unaligned and go uncorrected can have costly implications.
Kicking Things Off
Most of you have probably heard of the atage “Under-sell, over deliver”. What I have noticed is that sales people often have the opposite perspective – “Oversell and get the hell out of the way.” If you’re in an organization where you get handed projects, it’s even more important that you go in with this understanding. Go in with your eyes open, understand that there have been discussions and agreements that have been lost during the sales process but that the customer will be expecting as part of the deliverable.
Active Listening
What I have found to be very effective is (1) hold one meeting with the internal sales team and ask the difficult questions as they come and (2) have a meeting with the client to better understand what they believe they are getting. One you have both baselines you can figure out what and how big the delta is. But realize that this is only the important. Once you have engaged them separately, if approprate, call them together to walk through the things you’ve learned. The key here will be something known as “active listening”
Active listening is a way of listening and responding to another person that improves mutual understanding.
I myself struggle with this every day, but it is indeed imperative to being a good project manager or solutions architect. If you take the time to listen to the engagement and interject only to help guide the conversation you’ll find yourself deciperhing a lot more information. You’ll get a lot of those “oh, yeah, that’s right” or “that’s right, we did talk about that”.
This would also be the time that you bring things up that you might have identified as a delta after your discussions. “Hey guys, one last question, seems we talked about developing this pluging to be supported across 4 distinct CMS’s, that right?” or “Hey guys, just to clarify we’ll be deploying this on IIS instead of Apache, right?” This is the time to get those things straightened out.
This is also the time for you to lay out what you have heard and repeat it in your own words. Don’t repeat it in their words, instead digest and regurgitate back to the client and sales guy the way you’re interpreting the message. I think this is very important. You don’t have to get crazy on the technical details, but you should demonstrate that you have absorbed their needs and have started to relate the needs into technical requirements.
Documentation
This is but the beginnng of managing expectations. All that we have done up to now is set the foundation from which we’ll work with. Ideally you’d document what you’ve discussed, but look, the reality of the situation is you’re probably workig on a small project (I classify small something less than $10k) or so and if so, the project budget is such that it doesn’t support exhaustive documentation. In these situatons I employ tools like BaseCamp or SharePoint to quickly articulate the key points and move on. Some how, you need to put your thoughts down. For smaller projects I normally like to have the client document their own needs. This is really helpful and it takes the load off you and your budget.
Look, I hate documentation as much as the next person but it’s part of the process. I don’t care what methodologies you employ (SCRUM, XP, Water Fall) somewhere in the process you document something, whether it’s on index cards you paste to your white board or long drawn out technical documentations. It’s for good reason too folks, it will save you when you’re in a bind.
The thing to note though is that every one has this misconception of documentation. They see the label “document” and they automatically think dissertation of sorts. You need to put it into perspective. Sometimes that is what is required, others it is not, you as the manager have to put it into perspective. Once you do, you put it into perspective with your client as well. If they want a long drawn out document then tell them no problem will do and oh, by the way, here’s the bill.
Quality and time isn’t cheap, don’t forget that.
Communication
Ok, this is, in my opinion, the most important section of this post. The key to managing your clients expectations is simple, communicate. Setting up recurring calls is good, but don’t let that stop you. Engage your client, ask questions, keep them posted, go over the requirements. Don’t be afraid to tell them if they are wrong or misunderstand. The longer you let their expectations become misaligned the worse it’ll become for your project and yourself.
We have all had those clients that like to scream and holler when they don’t get what they want and like to believe you’re doing them a service and as such should do whatever they ask. I am here to tell you that is not the case folks. Don’t allow yourself to be bullied around. Don’t be a turd about it, but if they’re wrong they are wrong. If you require a change order, then so be it. Now, that being said, similar to the documentation, put it in perspective. If the cost of the change order is less than 5% – 10% of the total cost, you have to ask yourself what the real return on investment is to go through the bother of a change order.
On the flip side, it’s good to understand that you are not always right as much as you might like to think. Sometimes you have to “eat some crow”, that beng said I have had good experiences on recent projects being open with my clients.
I do caution you though, be careful not to become a “yes” man. It’s ok to agree and encourage innovation but be sure to differentiate between good ideas and good ideas that will get implemented on the existing project. Be sure to follow it up wth a “Hey, I love that idea, let’s plan on that next phase” or “Yeah I agree, that’s a good point, we could look to drop this feature for that, what do you think?” I have learned that your client will respect you more if you give it to them straight, not doing so will catch up with you at some point.
Pulling it all together
In summary, there are three things I recommend when trying to manage a client’s expectation:
- Active Listentng
- Documentation
- Communication
I have worked on small $500 jobs up to $5-$7M pojects / programs and I have yet to see where these three basic principles did not have a positive affect on my project, more importantly my sanity.
The bottom line is this, if you’re working on IT/IS related projects the odds are agaisnt you, recent studies show that 70% of our projects run over budget and / or schedule. The one thing you can control is expectations, in most cases, and what’s even more frustrating is that it is a relatively straight forward process. Learn to listen to what your client is tellng you, make an effort to capture those fragmented thoughts in your head and finally engage your client more than once a month.