Setting realistic expectations for deadlines

Question

I'm a tech lead for a small team. One of the major tasks on my plate is communicating with the client. One thing I find particularly difficult is dealing with deadlines because they are mandated by the client and I'm frequently not consulted.

Usually, the interaction follows the following pattern. The client comes up with a feature they want to add, Feature X. Feature X would look good in the next week's app release that is about 6 business days away. At this point, the feature request needs to go through approval and there are frequently other dependencies that need to be deal with. Eventually, N days later, the feature request trickles down to my team. Even if the original dead line (that was set by a non-developer manager) was achievable it no longer is. My team is blamed, feels discouraged and there's an overall atmosphere of defeat, I feel discouraged and defeated.

Clearly the overall process is broken. Unfortunately, there's not much I can do because I'm not in a position of power here. My current approach is to gently remind the client about our start date versus the deadline, the scope of the Feature, etc. This feels a lot like I am making excuses though.

Have you guys been in similar situations? What has/hasn't worked for you?

Answer 1

You really need to talk to your boss about this and set some ground rules:

• A deadline is not a deadline unless you commit to it.
• An estimate is not an estimate unless you give it, and then it is an "estimate" not a hard deadline.

Robert Martin's Clean Coder has a really good chapter about how to communicate this stuff to your boss. It is not your fault if the sales team is making impossible commitments.

When you get a new feature YOU estimate it and use PERT so you have a probability distribution. "I should get that done in 4 days but it may take as many as 8". Stand your ground. NEVER negotiate an estimate with a salesman, you'll end up committing to the impossible.

After a few iterations of this the salesman will hopefully get fed up being made to look a fool and will adjust behaviour to "I'll check with the development team and see when we can get that done" rather than a promise that you end up breaking.

Answer 2

Have you guys been in similar situations? What has/hasn't worked for you?

Mostly what works is speaking truth to power.

Gather the facts. Present the facts. Leave the customer to learn (or not learn) at their own pace.

My team is blamed, feels discouraged and there's an overall atmosphere of defeat.

Why is your team aware of the blame? If the customer is bypassing you and talking directly to the team, you're being rendered ineffective, and need to figure out why.

Your team should be ignorant of "blame" or lack of blame. They should simply build software, and you should simply communicate to the customer what you're doing and when you're doing it.

The customer should --- eventually --- grow to understand the process. It takes a great deal of repetition to break bad habits. A great deal.

Answer 3

I've been in this exact situation and it wasn't pleasant. However, one approach I did was to meticulously keep a record of work that is currently in development. When tasks come along, you remind the client, management or project manager that other work is going to slip as this has now become their priority (sometimes that can make them second guess and then you keeping pushing to get the deadline lengthened).

Otherwise, I guess you need to try and keep hammering that chisel into the stone wall that is the project manager/customer liason/management/salesman that is dealing with the client and agreeing to these deadlines. I often hammered the fact that if they agree that something will take 5 days to do, then they obviously are talking about 5 days development which means it takes 5 days from when you get it (not when they hang up the phone together and then spend the next two days drafting a fancy word doc).

However, since you are the development lead any decision such as this is irrelevant if not consulted with you in the first place.

You also need to try and shelter your team from this as much as you can. Although it's hard they need to be kept out of client/management politics as much as they can. If this is not the case, more head hammering is required.

Basically, I didn't enjoyed it and no matter how hard I battered the process didn't become perfect. However I did manage to improve things somewhat.

Answer 4

The only thing you can probably do is talking to customer. Just describe what happens as you see it, describe all the risks and so forth. I had a similar situation and I was really mad. Even now, when I'm responsible for all the technical estimations, I often hear - we want it done by Monday. I just say - you won't get it, let's discuss what exactly you'd like to have by Monday, and then often it appears that all the critical features are quite easy to implement and Monday is absolutely fine. All other features are then scheduled for later releases.

The problem is - customer mostly know business value for the feature, but don't realize its complexity. Just discuss and clarify. Always.

Answer 5

It's a good start that you're reminding the client that your start date is later than the date they request the feature. You also need to talk to whoever does the initial talk with the client to get details on the feature so that they can tell the client at the time what a better deadline would be. Since you're already in communication with the client you could just say "so who was it in Dept. Y that agreed to this deadline?"

If they won't let you in on the talks or they tell you to be quiet and take the deadlines they agree to, you can remind them that it would look better for the whole company if your team was on-time , and the way to achieve that is getting your input on deadlines.

Answer 6

Fix the information flow.

• If you are supposed to communicate with the client, force all project stakeholders (including the client) to interface directly with you, always.

Sadly, power is mostly taken by yourself rather than granted to you by others.

Answer 7

One of the major tasks on my plate is communicating with the client. One thing I find particularly difficult is dealing with deadlines because they are mandated by the client and I'm frequently not consulted.

If you are supposed to be responsible for communicating with the client, why are you not consulted on scheduling (and budgeting) so you can communicate this information between the people responsible for them within your organization and their counterparts at the client's side? I think that fixing this issue will be a huge benefit to you, your team, and your project.

The client comes up with a feature they want to add, Feature X. Feature X would look good in the next week's app release that is about 6 business days away. At this point, the feature request needs to go through approval and there are frequently other dependencies that need to be deal with. Eventually, N days later, the feature request trickles down to my team. Even if the original dead line (that was set by a non-developer manager) was achievable it no longer is.

This system for scheduling seems odd, to say the least.

In my experiences, the client signs on for a particular release. They might submit a list of features and changes they want and when they want them, and then negotiate with the team building the software. Or they might give a prioritized list of features to the development team, and the development team provides estimates as to when they can ship various sets of features. There are other variants, as well.

But one thing I've never seen allowed is a customer being able to change the release so late in the game, especially not a week away from a release. That doesn't seem right to put the designers, developers, and testers under that kind of pressure. If you are doing iterative development, if it's a high priority feature, just be sure to add it to the form of backlog and take it as soon as you can. If it's not a high priority feature, they definitely don't need it during this release and can wait until the next.

I would recommend setting some ground rules that accommodate your design, development, testing, and delivery teams as well as your customer as to feature freezes, code freezes, and deliveries. Put these in writing, get commitment from everyone, and stick to it. If you budge once, you'll be expected to bend more, and you'll lose control of the process.

Unfortunately, there's not much I can do because I'm not in a position of power here.

You might not be, alone. But it sounds like your designers and/or developers and/or testers are under a lot of pressure to meet schedules. You should have a sit down with your superiors as a team and explain the situation. First, get your organization to commit to improvement in the process, then work with the client to get their buy-in into how things are going to work.

This feels a lot like I am making excuses though.

When you start to make excuses, it might be time to have a Difficult Conversation or a Crucial Conversation. I would recommend one of those two books. Reading them has helped improve my communication skills, especially when you need to face a difficult situation where tensions are high on all sides.

---

To address some of the other answers.

Sadly, power is mostly taken by yourself rather than granted to you by others.

I don't know where Andrea is going with this. Yes, you need to fix the information flow. But you need to work with the PMs and client to ensure that everyone knows what was (I'm assuming, anyway) agreed upon at the start of the project. If the arrangement, for any reason, isn't working out, revisit it and redistribute work and roles to people better suited to them.

You don't take power or fight power, but you work with it, trying to tame it and make it work for everyone.

The problem is - customer mostly know business value for the feature, but don't realize its complexity. Just discuss and clarify. Always.

This quote from loki2302 is pretty much spot on. One of your jobs as a software engineer is to make sure that the right people know things like how difficult a task it, how long it's going to take, and what kinds of options and risks exist in doing something. As the lead communicator for your team, conveying this information from your organization to your customer is, in theory, your job.

Answer 8

Find a forum to approach whoever is setting these deadlines. Let them know that they can should consult with you and present something more realistic. The alternatives are: you can tell the client it's not going to happen or they can tell the client.

You can present it as you can do it in X number of days once your team starts working on it. Maybe that was the confusion? It's an honest mistake unless it happens over and over again. Then it's just neglect.

I'm guessing your team has met these deadlines in the past.

Answer 9

Unfortunately its endemic in our industry, so many digital/software agencies know nothing about the inner workings or requirements of their company. Many are only concerned with quick cash. As many have said before if you aren't providing the estimates or the deadlines, then inform management. How is it possible to deliver a technical piece of work by x time without an estimate from a technical person who is aware of the development team's schedule.

If all else fails, leave.

Answer 10

Give the Project Manager / Boss / Client the your achievable estimates and schedules, ask him to confirm your plan, or work out what he wants you to work on first, then walk away - do not engage or entertain him in any way.
If he comes back with a project plan that does not reflect your estimates, fire it back to him, with a statement, "I do not negotiate estimates." and walk away.

Make sure you have plenty of CYA documentation. Make it clear to everyone involved that you are keeping these documents. I have Emailed such records to my personal email address and CC'd my boss, which was very successful.

Answer 11

Here's an approach that should come across as constructive instead of finger pointing. I'm not accusing you of this, just saying it doesn't play well to have an excuse with someone else at fault regardless of the truth of the accusation.

After this happens, do a post mortem to calculate how long it actually took to complete the project, or would have if you had finished it. Then calculate how many resource hours you had available from the time you had enough information and the green light to work on it. Convert these numbers into how many additional programmers it would have taken to meet the deadline.

Now have a conversation with your boss along these lines:

We had X available man hours between project start date Y and deadline Z.
The project required X+C man hours to complete.
There have been similar turnaround requirements on other projects.
We will need Q additional programmers to reach the capacity needed to meet expectations.
...of course, if budgets are tight, maybe we could work with the Project Managers to build more time into their estimates so we can under-promise and over-deliver (be sure to use trite management speak)