5 ways to keep your client in the loop

Software is expensive to develop. We all know that and are more than happy to charge our clients our true worth. For worthy clients the amount is not the issue, the project will likely net them multiples of whatever you charge.

Imagine yourself as a businessperson running your own bakery. You sell cakes to the local neighbourhood residents. You meet this awesome developer who promises you that they can boost your business by 100* if only you could enable customers to order online. This sounds like a good idea and you are all in, you invest 5 month income worth of your business to building the product.

A timeline of 8 months is agreed, contracts are signed, deposits are paid everyone is happy.

One month down the line you walk by the developers office to see the progress done so far. The developer tells you that they still are setting things up but are fully confident they will make the deadline.

3 months after commencement you once more walk to the developers office and you find that they have not started yet but claim their machines are all setup. You are told that there was sufficient slack allowed in the schedule and there is still so much more time to get work done. You are a bit apprehensive but you comfort yourself, after all this guys are professionals, surely they must be.

5 months later there is now some progress and they call you to their office. Eagerly you wait as they open up the first page of your brand new web app which looks freaking fantastic! You love the landing page, the color scheme is amazing, truly reflects the essence of your business. You try to click the link to login and are promptly stopped from doing so. As it turns out the page you are looking at is the only thing that has been developed.

Our story ends here, you see it does not matter even if the developer somehow delivers the project in the three months remaining, the project is already failure. The obvious reason is that the product will not have taken the clients feedback into consideration. Even more insidious, the developer forgot a basic tenet of software engineering.

    Perception of slow development can affect your project as much as the reality of it.

You see, it is part of the developers job to provide their client with steady signs of progress.

So how could the developer have gone about this task? That is what this entry is all about.

Standardized requirements and checkoff

In a previous entry I talked about Investing in user stories. A side benefit of using user stories is that they easily avail themselves to be broken down into developer tasks.

Developer tasks are actionable items to be carried out by developers.

By breaking down the project into such tasks. Progress can be made visible as tasks are checked of and then entire user stories are marked as done.

Status meetings

Now I hate meetings as much as the next guy. But truth is that the most effective form of communication happens face to face. This meetings don’t have to be long, they just need to be regular.

Scrum practitioners have mastered the art. Their meetings are called daily standups and last a maximum of 15 minutes. All team members answer the three questions:

  1. What did you do yesterday
  2. What will you do today
  3. Are there any blockers

Status reports

Ok maybe the idea of regular meetings is too hard to swallow, what about regular reports? The basic idea is the same as meeting but now people submit their progress via email or chat.

This can be more convenient since a record exists and the reports can be done asynchronously.

Milestone reviews

As a developer, you should only write enough code for the client to review. At project onset, you can decide this review periods and set them as milestones.

Bonus points if you can tie compensation to this events.

By having clear milestones and reviews, the client is kept in the loop and their feedback is integrated on future iterations.

Walking around

Yes I know developers are professionals and don’t need someone watching over them. But this has nothing to do with the developers. By giving the client a chance to come to your office and basically walk around seeing your scrum board, burn charts, design diagrams etc. They get pleasant warm feelings about the progress of their project.

I hope it’s clear to everyone why its important for clients to have this feeling.

How do you keep your own clients in the loop? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to give critical feedback

You get a frantic call at 2am at night from your most valuable client, their payment processing page is returning a 404. You jump quickly out of bed and login to github to see what changed in the code. You note one of your junior developers merged his local test branch to the main branch. What do you do?

The story above may seem convoluted but many product owners have nightmares of it and even more have seen a version of it play out in real life.

But today we are not going to go technical and talk about version management, no, today we talk about the developer. Yes that is the human being who just messed up.

Faced with this situation your initial reaction maybe to simply jump at this persons neck and strangle them, 18th century style. Yet doing this would be the most ineffective way to handle the situation.

In this entry we talk about techniques of giving critical feedback.

Bad news does not age well

Don’t keep the feedback to yourself no matter how bad it is. Tell the concerned individual as soon as is reasonable.

Telling them the news early allows them to see the effect of their mistake on you, the client and the organization.

The devil vs the person

Back in primary school, our disciplinarians used to cane us while saying “It’s not you am caning, its the evil inside you”.

In our anger it becomes hard to separate the person from the behaviour. No, your developer is not the devil reincarnate she just made a mistake, thats as human as it gets.

Point out the specific behaviour and have her correct that.

Get to the point

Illusion of transparency is a phenomena in which an individual overestimates the degree to which their personal mental state is not known to others.

With this information in mind, you may realize that the developer probably has no idea why you are fuming. If you fail to give specific feedback he will overtime come to the conclusion you are neurotic, a person to hide from, not listen to.

As a power tool, you may want to have the offender rephrase the problem he caused and the steps he plans on taking to prevent such an occurrence in the future.

The folly of sandwiching

The sages of old said it “If you wish to give bad news, first start with good, then the bad and finally more good”. This is really tempting to do since we want to protect the feelings of the recipient of the bad news. Yet in practise it never works as expected!

You see we humans are particularly adept at selective hearing. The developer will hear all the words but only remember the good parts. Not ideal to inspire any changes wouldn’t you agree?

Positive reinforcement

Sandwiching maybe a bad idea but that doesn’t mean you should throw appreciation out of the window! What you need to do is actively look out for changes that you want to see and reward them as they occur.

Negative actions and behaviours have a powerful emotional impact compared to positive ones. You must always be looking to compensate for this bias. Better to err on the side of compliments.

How have you dealt with mistakes in your workplace? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail