Norm CRM
Back to contents

Chapter 22

How not to do everything at the last moment and not be late

This is an automatic AI translation, not verified by the author.

You can truly manage deadlines if two conditions are met. First, the deadlines are announced by the freelancer, not the client. Second: the timing does not depend on third parties.

With the first, everything is clear: the performer estimates how many hours he will need to solve the problem, checks the calendar, sets aside time for illness and other unforeseen circumstances, takes a small reserve from above, and only after that names the deadline.

I myself, when I take on a task that requires a week, usually say at least a month. If I deliver the work ahead of schedule, no one will be upset. At first, I was afraid that if I estimated the duration of the work to be a month and did it in a few days, I would raise a lot of questions from the client: why did he pay so much for such a “short” task. But in practice, firstly, customers were only happy when they received results ahead of time, and, secondly, this happened extremely rarely. Knowing that I still had many days of work ahead of me, I did not rush things.

Of course, this led to me sitting down to the task late and turning in everything at the last moment, almost missing the deadline. Something had to be done about this, and I began to try different options.

At first he gave very tight deadlines. This led to overtime, including overnight shifts, as well as several projects completed late. In addition, the clients themselves often could not accept intermediate results at the same speed with which I provided them. And then they had to either reschedule or agree to what I showed them. Ultimately, customers remained dissatisfied.

Then I returned to adequate deadlines, but structured the work in such a way as to show the client the first intermediate result two to three days after receiving payment. The customer didn’t expect much from me during such a period of time, so even if I couldn’t shake it off and sat down to the task literally a few hours before the demonstration, this was enough to get started.

I liked this approach and began scheduling interim negotiations almost every day. This not only saved me from avoiding work and moved me forward, but also turned out to be very effective in terms of moving with the client towards a common vision of the result.

After all, I received comments and feedback almost instantly, took them into account in the early stages, and by the end of the work produced a result that was ideal from the client’s point of view.

Over time, I balanced this approach so that, on the one hand, I did not overload clients with intermediate negotiations and, on the other, I did not allow myself to be distracted from work for a long time. And after a few years, the habit of this approach developed on its own.

So I outsmarted myself. I created conditions where it was impossible to submit work on the last day, but at the same time you could still sit down for it late, several hours before the start of negotiations.

I don't like working with a calendar, as it turns my wonderful free life into a set of regulated events waiting in the wings. But when there are several projects in progress, you can’t do without it.

Instead of a full-fledged calendar, I became addicted to using small notes where two types of dates were arranged in chronological order: deadlines (the so-called deadlines for the final delivery of work) and negotiations. The list looked something like this:

  • 06 Oct, Thu: 15:40, negotiations with Andrey
  • 06 Oct, Thu: 17:00, negotiations with the auction team
  • 10 Oct, Mon: 12:00, negotiations with Igor
  • 11 Oct, Tue: deadline for cars
  • 13 Oct, Thu, 16:00, negotiations with Anna

That was enough. In my work, there have almost never been such a large number of events that a reminder system was needed. The list grew down into the future, and when the top events happened, I simply deleted them.

Being late for meetings is unacceptable to me. I operate according to the principle “You can either arrive early or be late for a meeting.” As I already wrote in the chapter about the first negotiations, I am on alert ten minutes before the start. The equipment has been tested for performance, a backup Internet channel has been prepared, I am in a quiet and comfortable place. If video calling is used, I look neat and make sure the room is tidy.

During live meetings in offices, I similarly arrive early and well prepared. In order not to be late for an event in a big city, it is necessary to take into account additional risks such as traffic jams, delays at checkpoints, and the weather.

Sometimes I play it safe enough that I get there half an hour or even an hour earlier. In this case, I always have a book or work in stock that can be done while waiting.

If I’m still late, I understand it long before I’m late. Even if there is just a small risk, I still call the client and warn him about the delay. I apologize, explain the reason, if appropriate, and also tell you the exact time you can expect me to appear.

Such calls are an extremely unpleasant event. There is always a desire to quietly catch up. And it's okay if you're only sixty seconds late. But for a person waiting on the spot, this minute may be decisive in deciding not to cooperate with an unreliable person. There is nothing wrong with being late, because sometimes events arise that we cannot influence in any way. But a warning call is the responsibility of the late person, and there is no excuse for keeping your interlocutor in the dark.

In the same way, it is important to warn in advance if the project deadlines are delayed. The structure of the warning is the same as for late meetings: an apology, a reason (if appropriate) and a new date. In fact, it is usually only appropriate to voice the reason if the client has asked for it. The question “Why did this happen?” is not as important as “What do we do next?”

Unfortunately, I don’t know a way to overcome the fear of informing a client about being late or rescheduled. You just take it and do it. The first time it was very difficult, then it became easier and easier. The main thing is that with experience, the skill of estimating deadlines grows faster, and not the skill of fearlessly reporting postponements and delays.

At some point, I became so confident in delivering my work on time that I began to guarantee it with money. I informed clients that if I missed the deadline, they would receive both the result of the work and an advance payment. Then it seemed to me a very cool marketing ploy, demonstrating how reliable and confident I am in my abilities. But, having been in the client’s shoes, I looked at such a proposal with different eyes. A person who is ready to return an advance payment for work done (albeit late) does not seem to value his time very much, and if he is late, he can return the money and leave the client with an unfinished project. As a result, I abandoned this wording and returned the good old line about penalties to the contract.

Sometimes I had to work with clients who dictated their own deadlines. At first, I assessed my capabilities, decided that I could handle it, and boldly took on such tasks. But almost always nothing good came of it. The fact is that a client who declares that he needs results by a certain date will almost always be an incompetent manager who does not understand that the speed of work completion is an individual parameter for each performer and that such people must assess their strengths and capabilities themselves, taking into account their other projects and plans.

A good manager will first ask the freelancer to estimate the deadlines, and only then can try to somehow influence them by offering especially comfortable and favorable conditions. He will not immediately demand results by a specific date.

Managers who don't understand this are not only inadequate in their demands. They are inexperienced and ineffective at work. This means that, having contacted such a client, you can expect that he will not be able to quickly resolve emerging issues and make intermediate decisions without slowing down his work. On the contrary, the faster my clients needed results, the more destructive their comments were for the projects.

Sometimes we spent an inexcusable number of hours discussing minor details. Sometimes clients skipped mid-term negotiations because they had other fires to put out. It also happened that on the day of delivery the customer disappeared and appeared a week later, demonstrating that the strict deadline was, apparently, a way to force the performers to work “faster” and “more efficiently.”

Just a few cases of cooperation with such clients were enough for me to formulate a policy for working with them:

  • If things are going well and there is a choice between clients, then you can simply refuse customers with tight deadlines.
  • Before starting work, I immediately drew up a plan for interim negotiations for the entire period and agreed on it with a note that in case of violation there would be fines both in terms of delivery time and in money.
  • I refused my company guarantee in money that the client would like the result. In the case when the customer sabotaged the work, he made the project so that by the deadline it formally met the functional requirements, and assessed the edits separately.

Let me summarize. When managing deadlines, I adhere to the following principles:

  • I try to outwit myself and put myself in such conditions where it is almost impossible to break deadlines.
  • If I see that I don’t have time, then I warn the client well in advance, and not at the last moment. I perceive such situations not as failures, but as points of growth. By making a mistake today, I gain valuable experience and save myself from making the same mistake tomorrow.
  • If life forces me to work within someone else’s deadlines, I greatly tighten the terms of cooperation in order to both maximize the chances of a good result for the client and protect my time, nerves and reputation.
Back to contents