Visualizing your IT gut feeling

Or in other words: The inherent unpredictability of IT projects.

The "standard" IT feature

After about two months of being hired at my new job, I was asked to implement a very serious feature, related to the Corona / Covid-19 measures. This feature was particularly important for the customers, because it would allow them to start up their business again. But the funny thing was, I wasn't really familiar with the platform yet.

As these things go, the CEO asked me: "This-and-this is what we need, how long will it take? When will it be ready? When can I tell the customer it is finished?" First I said: "Well, I don't know. It's difficult, because I don't have an overview. So I can't really give an estimate right now." Naturally, my boss said: "Yes, yes, but the customer really needs it in one-and-a-half weeks, or actually two weeks." Then I told him: "Well, we can try. So far, I think if we do it in this-and-this way, we should be able to manage it."

But saying that was actually my first mistake. Of course during this one-and-a-half week period, during the first few days we actually found out that it was not one-and-a-half weeks, but only one week. Then talking to the customer, elaborating more on what was going to happen, they came up with: "Yes well, we also need time to instruct our employees..." So in the end, we actually just had a few days to implement it. Of course, the project took longer than expected.

Basically, this is the standard way IT projects go. They need a feature, they need it yesterday, please make it as quickly as you can. So what I did: I started working overtime. I worked from like 07:30 in the morning until 11 in the evening, I started working during the weekend and during my other free days. I started accumulating a lot of hours extra above my regular contract, which is fine in itself. I can compensate these hours, my CEO also said it's fine and I can take extra time off when the feature is finished. And mind you, this is not a CEO that has a feature that needs to be implemented yesterday, every two weeks. This was a one-time thing. At least, this was my experience with the customer at this company.

"Preventing" recurrence

Of course, I already told myself: "If, in a few weeks, another feature like this is going to come in with this kind of pressure, should have been finished yesterday, I will say: Look, we've already had this, my experience with it was quite bad and I'm not going to work overtime every couple of weeks, because I'm not going to be able to manage that, I am going to get burned out, I'm not going to get paid enough because I am never going to get enough time off to compensate for the extra hours."

But, putting that aside, what happened here? The customer puts pressure on us, because the customer wants to start up their business again. They're losing money, their costs don't go away, it's a serious issue for them, which is perfectly understandable. And we want to help the customer, we want to keep them satisfied. We also want to give them happy prospects that they will manage to start their business again and that we can do it. Because if we say early on that we can't do it, or that we're not sure, then we are afraid we will lose the customer and in the end, this might result in more problems for us, because this particular customer brought in a lot of other customers, so there's a risk this customer will leave us and talk to the other customers they brought in, making them leave us as well.

This might actually result in our company going broke. So we wanted to provide the customer with happy prospects, even though there is this gut feeling inside telling us: "I'm not sure we can do this, I shouldn't be saying this, I shouldn't give these rainbow prospects that everything is going to be cool, everything is going to work out, when I know that I can't be sure of this at all."

This time will be the last time

So what happened during the next the week after that moment? I started working overtime, implementing things, indicating a couple of times that it's more difficult than we expected, I found out that I don't have a full overview, there were some unexpected setbacks. We talked to the customer a lot, showing the things we did manage to finish. Naturally, the customer said: "Ah, but this is not what I want, I want it like this-and-this-and-this." So I said: "Alright, but that is going to take extra time". So the CEO said: "Okay, so how can we simplify this? How can we cut the time short and still deliver it on time? Not with full quality."

Then I started making concessions on quality, which I promised myself a while ago I wouldn't do. I've been developing software for over thirty years, I don't want to make concessions on software quality anymore. Why? Because in the end, it will always bite you in the tail. Delivering something quickly now, there's this consideration that the customer is happy right now, but then later on you'll have to change something and then you think, what was this? It was made quick-and-dirty, it's difficult to understand, it's missing documentation, I'll have to figure it out again, this will take more time...

And then you think: Ah, but this is not good, because the next time I have to make a change, I'll have to figure it out again and again, or my colleagues will have to do it, so I'd better document it properly and/or reengineer it better, next time... it will take more time. So usually these things will bite you in the tail and when the quality is lower than you'd like to admit, then you're not really proud of what you make, you start to be unhappy about it which really puts the pressure on your motivation to still finish it, and this is a vicious circle spiralling down.

The root of the problem

What is actually the root of the problem here? It's not anybody's fault, that's the first thing. As a company, our customer has a lot of pressure on their business, completely understandable, perfectly fine, and they relay that pressure on us, very logical. I would have done the same if I were in their position. But the error we make, is to give the customer a very rainbow happy prospect, of which we actually knew we were not sure. So what starts happening, is that we start disappointing the customer and this actually helps getting rid of the customer!

It is always better to disappoint a customer upfront, instead of later on. If you know you're likely going to disappoint him/her, or if there's at least a risk of disappointment, do it as quickly as possible. Then, you're being honest, you're being fair and you're managing the customer's expectations very well. Yes, even if you have to disappoint them. You can say: "What you're asking is perhaps possible, but we don't know." With that you're saying: "We are going to do the best we can for you, but we simply don't know if we'll manage. We don't have a crystal ball in which we can look and see that it will be finished on this-and-this date and this-and-this time, it will work perfectly and fulfill all your expectations, even the ones that are going to change in a few days." We don't have this crystal ball yet, maybe in time we will. It would surely have been great to have one of those already now!

Managing expectations

But, you're managing expections. Like an old colleague of mine, a good friend and good project manager said more than once to the other managers: "What do you want? The customer is putting pressure on us, that's fine. Do you want to disappoint the customer now, or do you want to disappoint the customer in two weeks? Either is fine with me." And that's actually the thing. If you're in a project, you can only give a reasonable time estimate, time to market, once you can oversee the entire feature, once you can oversee all the tasks that need to be done in order to realize this feature in a way that satisfies the customer.

If you can't oversee it, there are two options. Either you tell the customer: "We cannot oversee it, so we don't know how long it's going to take, so we can't give you a deadline, we can't give you an assurance on when it's going to work." The other option is: "We are going to invest time into finding out how long it's going to take. So we gather more information in order to determine all these steps that are required to implement the feature, to get them clear and put them on a list. This way, you'll have a reasonable assurance that these are the steps we need to take and there won't be more steps and very few surprises."

But as the customer is already in a hurry, you will also have to tell them: "We can spend time on improving the estimates, but this time we can't also spend on implementing the actual feature. This means that if we start now with implementing it, it will be done sooner than when we first spend time on estimating the deadline. Because after that, we still have to start implementing it." And yes, normally, when you do the estimates, you also learn about the implementation, so the final implementation will be a bit quicker. But still, in the end, the final implementation will take longer when having to make estimates beforehand.

When you tell this story to the customer, the customer will very unlikely be happy with the answer. "I don't know how long it's going to take." The usual reaction of them will be: "But you should be able to give an estimate, right?" "You have a gut feeling, you have an idea of how long it's going to take. It's not going to take a year, right?" And you'll likely say: "No, of course not. It won't take a year." It's not going to take a whole full month, right? Probably not. It's going to take weeks, but I don't know how many weeks. But I know it's very unlikely it will be finished in a few days.

The customer then probably goes: "But it should be surely finished within three weeks right? Maybe two?" And the reply will likely be: "Well, I don't know again, maybe..." Usually this is the point where, just to keep the customer happy, to get rid of the customer, stop talking about the estimate and start working on it, you might say: "Yeah, I think it could be done in two weeks", when you actually know it's going to take three, four or five weeks. We simply do not know yet.

Either way, the customer is actually pushing you to disappoint the customer, which is really weird. The customer wants a happy answer, but the more the customer pushes, the more likely the happy answer will not be correct. So this is a kind of strange dilemma. As a software developer or IT architect, in the end you still have this gut feeling. It's not going to take a year. It's not going to take six months. Sure, within two months, I can give you a 100% assurance that it's going to be finished for sure. Even if I cannot oversee the entire trajectory or all the steps. Surely in two months it will be done, that I can guarantee.

The expectation management graph

But, two months is way too late for the customer. What you actually want to give the customer is something that he can still use and also manages the expectations of the customer correctly. So the ideal response at this time would be a graph. So my suggestion is, at this time, you present the customer with a graph. We don't know when it's going to be finished yet, we're not sure. But we know it will surely be finished within two months and there's a 60% chance it will be finished in one month. Again, we're not sure. There will be an 80% chance it will be finished in one-and-a-half months. We're sure it won't be finished within a week. Definitely not. There is a 10% chance it will be finished in three weeks.

So what you want to provide the customer with, is a graph setting out the percentage of chance against the time of delivery. This is the graph that the customer can work with. The customer always has his own schedule, he needs to know like: if it's finished then-and-then, or between then-and-then, or the chance is more or less a 100% that it will at least be finished then, but it will likely be finished sooner, but it's not sure: I have these-and-these options. Then you are correctly managing the expectations of the customer. You're actually expressing "I don't know" in a visual graph in which you short-circuit the whole discussion "It's not going to take two months right? In two months it will be finished for sure. What about one month? And what about one-and-a-half month?" You're short-circuiting that whole discussion there, which also ensures that you won't be compelled to give the customer a happy answer just to get rid of them, so you can actually start coding. You also short-circuit that feeling as well.

So with this graph, you give a proper estimation and you actually feel satisfied. You're managing expections, you're not committing to something that you have this uneasy gut feeling about or you're not sure you can commit to. This would result in working over hours and all these related things you want to avoid. With the graph, you're still managing the customer expectations perfectly. The customer can then also decide: "Ah okay, in the end it might take two months, so what other courses of action do I have?" They can also make their own plans, given this graph of expected delivery time versus the chance that it will be delivered. With it, you're facilitating the customer.

In the end, this will result in, from my experience, a happy customer. He will have more faith in you, because you're not telling him fairy tales, but you're also not sending him into the woods by telling them "We don't know how long it's going to take". To provide a very good balance between those two things, creates a very solid foundation for trust amplification between the customer and you. This is what you want, because in the end everybody is happy with that and your assisting the customer in making business decisions on reliable information, which in turn helps their business. In this way, you add value to the business of your customer, which in the end is the whole idea of a company.

A word of thanks to this particular CEO for unconsciously throwing me into this evaluation of events, frustration, irritation and the thought process that resulted in this piece of, in my humble opinion, insightful reflection.