Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
10  
Leave. You can't win. You management is not protecting you, therefore they don't care about you. Leave. –  Christopher Mahan Jul 19 '11 at 19:34
4  
"This feels a lot like I am making excuses though."? Why? Facts are facts. What are you "excusing"? –  S.Lott Jul 19 '11 at 19:40
    
We don't work in a blackbox. When the team is dysfunctional there's only so much a powerless lowly developer can do. –  P.Brian.Mackey Jul 19 '11 at 19:43
2  
@EightyEight: The "line-out" technique doesn't clarify anything. It's either you or the team (or maybe both). But a line-out doesn't help anyone understand what your question is. It's okay to remove stuff that's not true or not relevant. –  S.Lott Jul 19 '11 at 21:21

11 Answers 11

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.

share|improve this answer
1  
+1 - developers/people who know what is actually involved not being involved in estimates screams crazy crazy crazy :/ –  elwyn Jul 20 '11 at 0:29
2  
'... a promise that you end up breaking.' - Never forget, and regularly remind people you can not break a promise you don't make, including ones made on your behalf. –  mattnz Jul 21 '11 at 21:28
    
"A deadline is not a deadline unless you commit to it." I liked that so much that I just tweeted it. ;) –  Bob Horn Apr 11 '13 at 2:20

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.

share|improve this answer
    
+1 "speaking truth to power." Can you clarify please? I like the "ignorant of "blame" statement. I wish I could find a company that stopped all the mindless finger pointing. –  P.Brian.Mackey Jul 19 '11 at 19:45
    
"Gather the facts. Present the facts". I thought that was clear. What more can one say? –  S.Lott Jul 19 '11 at 19:45
    
I think I get it now. I just never heard that term before. –  P.Brian.Mackey Jul 19 '11 at 19:48
3  
"stopped all the mindless finger pointing". It can't be stopped. But the role of a team leader is to shield the team from the worst of it. –  S.Lott Jul 19 '11 at 19:49
    
The client doesn't talk directly to my team members but dissatisfaction with one's work tends to filter down no matter what. Maybe I should substitute "I" for the "team". Sounds like I'm on the right path. Thanks for your comments. –  EightyEight Jul 19 '11 at 19:52

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
Never accept a "...by Monday" deadline. That just means the devs will spend the weekend coding if the shit hits the fan. Use Friday as a deadline or, better yet, Wednesday. –  sbi Jul 20 '11 at 9:19

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.

share|improve this answer
1  
Yeah, like that's going to happen. Although, if you did that, you would probably get fired and earn a bunch of respect from some of the people you work with, and from some of the customers (who are probably sick and tired of your company management too). –  Christopher Mahan Jul 19 '11 at 22:39

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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)

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.