Cutting Out Delays caused by Customers

Your project will not be delivered on time and to budget if you are not successful in cutting out delays caused by customers.

The biggest suppliers to the project are usually the internal or external customers of the project. It is a lot easier to manage suppliers to the project who are not customers. It is a lot harder to manage customers or users when they are in the role of supplier. They provide information at all stages, sign-off, facilities, test data etc.

When they deliver something late, e.g. information, it is difficult to report them to their superiors without causing friction. Any delay to the project caused by them will not be reported as such. It will be put down to you. You, therefore, had better fix it. Cutting out delays by users or customers will be crucial to the success of your project.

Cutting Out Delays – Crucial Mechanism

It is important to put a mechanism in place at the start of the project which ensures that any late supplying of information etc. is documented and automatically escalated. There should be a written agreement with the senior project sponsor or senior customer, i.e. whoever is ordering the software product. The project sponsor is usually happy to do this as they do not want delays to the project, with the resulting cost increases.

When a delay is caused to the project by any supplier, including the customer, a Delay Note should be issued. This delay note should document the cost in terms of scheduled days, elapsed time and money. This should be given to a senior IT person, perhaps the head of IT or of software development to be passed on to the project sponsor.

Cutting Out Delays – Automatic Escalation of Problems

This escalation process should be automatic so that the person who escalates it can say to their customer contact that it is part of the process. If the project is being done for an external customer, the costs of the delay should be passed on to them. This should be stated in the initial contract.

What will happen, usually, in practice, is that the customers or business users that you are liaising with will not take this seriously at first. They’ll have other priorities. They would see the current business as being more important than a system they’ll get down the line.

They don’t think you’ll report them. They don’t think you’ve got the balls to do it. They don’t think you’ll  jeopardise your relationship with them by reporting them to their boss. Therefore you must do it. The sooner you do it on the project the better – and do it to someone who the other users didn’t think you would do it do. They must think “if he does it to them he could do it to me”.

Cutting out delays is crucial or your project will fail.

Cutting Out Delays – Stamping Your Authority

It’s a bit like a referee stamping his authority on a game early on to show he means business and will not take any malarkey.

I did it on one project to my opposite number, a guy called Frederik. He was the Project manager on the customer side and I was the Project Manager on the supplier side. We each had only one person above us on the project. I reported to the MD on the project and Frederik reported to the project sponsor on the customer side.

It had been pointed out to me by the software Project Manager that, although Frederik was always very insistent that we had got everything done, he often didn’t have what he was supposed to do done. This may have been the supply of information or the supply of good test data. No one had ever called him up on it before. He was the customer after all.

Good Relationship

I had a very good relationship with Frederik. We got on well and we saw most things the same way.

So, the first meeting after it had been pointed out to me that he often didn’t deliver I said at the start of the meeting that every time someone (anyone) hadn’t delivered something that they should have done at the meeting I was going to start a game of hangman for them.

Gradually the gallows were constructed line-by-line and Frederik eventually ‘hanged’. I hadn’t set it out specifically for Frederik (or so he thought). It was for everyone. His lieutenants on the project could see it and our people could see it. He was the main non-deliverer.

Good Spirit on Project

He took it in good spirit and I was hoping that he would see the light and change his behaviour without my having to report him. He did improve for a while but then he started to deteriorate again – and it was something major. His lack of delivery on it would be a major impact on our being able to deliver the project on time. From memory I think it was the supply of test data. His would hold the whole project up.

I knew I had to act. I issued a Project Delay Note and gave it to my boss the MD. He contacted the Project Sponsor on the customer side without delay. It was Friday afternoon.

Bad Weekend

On Monday morning I was told that Frederik was trying to get hold of me. I thought I’d let him stew for a while. I waited till the afternoon to get in touch.

“I’ve had a very, very bad weekend he said in what sounded like menacing tones. “Was it raining in Holland then?” I asked him. “It was nothing to do with the weather” he replied. “I think you know what I’m talking about. You should have had the courtesy to come to me first”.

It seemed that his bad weekend had been caused by an almighty dressing down by a very angry Project Sponsor on the customer side, i.e. his boss on the project.

Automatic Escalation

“I was forced to do it”, I said. “It was part of the procedures that you signed off on. If I didn’t do it I would have been in trouble myself if I hadn’t”.

He said “You should still have come to me first”.

I told him that I had tried other methods like the hangman. However, he still hadn’t got the message. “This was a last resort for me” I said. I think grudgingly he accepted it. However, what was more important was that his behaviour changed. He didn’t want any more bad weekends.

Be Brave

It was an uncomfortable phone call. However, you have to be brave. The rewards are very high for doing it. Can you imagine a project where the customers or users deliver everything they should on time? What a bonus this would be to your ability to deliver the project on time and to budget.

And yes, this is what happened. There were no future major delays to the project. This was a highly significant factor in our bringing in the project ahead of schedule and making a good profit which impacted very significantly on the careers of the MD and of myself.

You must also keep a wary eye out for those that work on the project for you and make sure they escalate to you any problems that they are having with their opposite numbers and their deliveries to them. If you find out that they are not escalating delays to you then you should let them know in no uncertain terms that this is not acceptable.

Zero Tolerance for Delays

There should be zero tolerance on this. The people most likely to screw up the project for you in terms of getting it done on time and to budget (and making a healthy profit) are the customers themselves. Don’t let them do it. It’s an absolute certainty that they’ll try. Impress on your people how important it is to stop them doing so. Impress on them, also, that it will be a very grave misdemeanour if your people let their opposite numbers away with this without escalating it to you. It simply won’t be tolerated.