Completion time on a company where the supervisors don't know programming

Question

We are in a small company with around 10 developers. I am the team leader and responsible for the development process.

Supervisors and salesmen are close to us since we are a small team, but have no clue on how software is developed.

When they ask me how much time I want for a change (bugfixes/features) in a product, my response is 'let me calculate it'. After giving them the schedule, they start by saying OK you can do it in XX time which differs a lot from my plan. We are using a model close to Agile basic principles and have circles per week or per three days.

Of course I argue and say that this cannot be done. They seem to have no idea on the effort we are doing. They do not want to see WHY my schedule is for that amount of time.

I know this behavior is stupid, but how can I make them see the problem?

Answer 1

If the salesmen are also the ones who are in charge, you can say, "Ok, I can go with your schedule. Which features or responsibilities would you like me to sacrifice in order to make your deadline?" That way you're not saying "no" to the people in charge but you're not committing to impossible things. The decision is in their hands how to run the business. If they want to axe other things to make time for the changes, let them.

EDIT: We need to respect and submit to those who are in authority, while still doing our jobs with excellence. The only way to do this is with humility. I'll work on whatever my boss wants me to work on, but I can only do so much. When you tell him like it is with an attitude of submission, he is in a better position to make better decisions and he'll want more employees like you.

Make sure these things are documented too in order to explain why the commitments are unreasonable and how the situation was resolved. It can help coworkers deal with similar situations in the future.

Answer 2

In my experience Sales people think that everything is a negotiation where you meet eachother somewhere in the middle. That's basically how they work. They try to sell a product to a client and ask high, the client offers low and in the end a price both parties agree on becomes the agreement.

They also take this mentality to the workfloor. They assume you're asking for too many hours so they will try to argue off some of the hours, just as in a negotiation.

Giving exact estimates, has only given me headaches.

What you can do is play along: give a higher estimate where they can shave off some during "negotiation" and in the end, end up with the hours it really costs you to do.

Answer 3

Do not show them their fault!

Try to argue better what changes you make, give them more detailed estimates. Make a suggestion like "We can do this in your X hours instead of mine Y hours, if we will give software testing to outsource". Or "We can do this faster, if we exclude this part of requested functionality".

Answer 4

"After giving them the schedule, they start by saying OK you can do it in XX time which differs a lot from my plan." First of all ask them how they calculated their XX time.

Suggest to them that a record is made of your estimate and their estimate. Then you can compare the actual against the predictions and see who is more accurate.

Answer 5

Say "I stand by my estimate." And then of course hit your estimate. When it happens three times, they'll probably trust you.

Answer 6

"When they ask me how much time I want for a change"

At that point stop them. It's not how much time you want. It's how much time you need. If they insist, give them both the time you want and the minimum you need.

It may also help to keep a very visible measure of incurred technical debt due to all the shortcuts forced upon you by Sales. Nikolay is widely optimistic that you can influence Sales by talk, when their current behavior gets them bonuses.

In fact, if Sales is really driven by such incentives, then you should take that into account when formulating your response. "Feature not committed by Engineering" is a perfectly valid reason to drop a Sales request.

Answer 7

To get away from their preoccupation with hours, change the game. Instead of estimating time, estimate complexity in relation to some given usecase that forms a baseline.

You mention that you have something of an Agile approach, why not try Scrum?

In other words do short Sprints, tell them that "yes in one week I will be able to develop three of your five features" then make sure you deliver on those three features. Have them prioritize the changes/features/bugs and work strictly in that order. (Of course there is more.)

Teach them about the iron triangle of time, cost, quality and scope. You fix three and the fourth is the triangle area and thus a function of the others. I would guess that it is probably more important in the end when you are delivering, how much it costs and hopefully that you deliver with quality than exactly what you are delivering.

Answer 8

This is a huge bugbear of mine for sales/consultancy led projects and it's a tough situation. This is often an issue of how the company operates.

It is a classic case of the tail trying to wag the dog , sales guys doing whatever they can to close the sale, promising the world in features, and guaranteeing a ludicrous timescale, software development process and everything/one else be damned.

Either they will listen to you or they won't, it is not necessarily a fact they do not understand, more likely, they know fine well, but all they care about is closing the sale, getting the business and worry about deadlines later.

That being said, customers can be a pain in the backside, they want things done cheaply, and they want to know when it will be done. And they want a discount to boot.

One way to mitigate this is to have a tech guy involved in the sales meetings. Now this is not necessarily feasible in every company, but may be the only way to at least try and reign in the sales guys.

Answer 9

It might help to differentiate between how much time something will take and how much time will be charged. How much time something will take is a technical decision, they have no basis to disagree with you, be stubborn. How much the salespeople want to charge for that time is their decision and their responsibility to sell to the client.

Other than that the incentives need to be sorted out or you'll always be fighting an uphill battle. If sales bonuses are paid not on the outright value of the sale, but on the difference between the value of the sale and the cost of delivering it then they have an incentive to listen to you.

Answer 10

If they want to cut the schedule - ask them which features they want to be left out and the priority of those.

Then work on features in order of priority and tell them they can have they product whenever they like but it won't contain all the features they requested until the end date you specified initially.

Answer 11

If its a persistent problem, how about seconding a sales guy onto the development team for a week or two. Give them a book about the X programming language, and tell them to do it in their estimate. 99% of the time they will fail miserably, and be loath to question your estimates again. They might also get an idea of what it takes to do software development and realise they are not helping the process.

Answer 12

Make clear you are estimating the amount of time it will take, not promising you will get done in that time, and that getting you to lower the number is nothing more than talking you into lying to them. It won't actually magically make the software get done faster.

Ask them how much good it would do to talk a woman into lowering her estimate for her pregnancy from 9 months to 7 months.

Better yet, get a product manager. Salesmen will tie your product into knots chasing commissions, because they have little incentive to care about the overall product and every incentive to chase the current sale.

Answer 13

There are two issues, which need disentanbled.

1. Stop quoting in time, start quoting in dollars. This quickly allows them to do a cost / benefit analysis, and allows you to add a standard "time to analyze" quote. Time is too sticky, because it doesn't reflect the real amount of work done (forty hours could be done in a day, five days, or three weeks), and it is far too easy to not push the budgeted release cycle back for such a request.

2. Provide the sales staff a request input into the dev cycle (preferably a non-human interface, to save time (measured in money)).

Sales people tend to think in terms of (if I have X, I can close this sale). Their requests are often not coherent with the current architecture of the product, but they are coherent with the current need of a customer.

Indicate to the sales force that such requests are vital for your product, and as such, you need to not lose them in the "quick request, will take longer than the period of interest, drop the request, repeat" cycle. Such requests need to be captured, analyzed, prioritized, integrated into the product, tested, and released with the next release cycle.

Then back up your words with actions. Shorten the release cycle to under two months, indicate which items are going to be in the release, and hit your deadlines. Don't educate the sales staff about the internal reasons this is necessary, just do an analysis of what an out-of-cycle request minimally costs (in dollars), and what the risk (extra dollars and percentage of occurrence) it could cost if a problem exceeds minimal complexity. Then ask the sales person if the sale is large enough to support the out-of-cycle request.

Once they have a process for an in-cycle request, and they have an idea of how much it costs to handle an out-of-cycle request, odds are good that you can convert their out-of-cycle request into an in-cycle request, or determine that the out-of-cycle request is profitable enough to justify the expense.

Answer 14

Well, I'd hope that in order to commit to a piece of work, it's understood you and Sales need to agree meeting the requirements is worth the value.

Emphasise that unless you and Sales can agree, they can't make the sale and the job does not happen, so either you need to agree a counter-offer for the customer (smaller spec, longer timeframe, etc.), or else they need to find another customer.

There's no point signing a contract with a customer that you know you cannot fulfil, it will just end up taking up everyone's time and you risk losing the customer and others, and may not even get the money for the job.

Answer 15

If you feel your estimates are accurate and history reflects that use this.

When they say you have XX time, revise your estimate taking out features until it gets down to this time. Don't take out testing.

Then it is a negotiation about features and time, not just time, which history says you cannot change. If they insist on negating over time, start negoting bonuses for hitting said time (if you team is willing to work the overtime to get there). Say we can make the time you want, but it is going cost you a $1000 bonus to get there

Remind them that software development is like a factory and the factory is capable of producing X in Y amount of time. Goes to the bonus again, you can work overtime, but it is going to cost. Don't call it overtime either or they will just work you to death. It needs to be written down as well. X product by Y date for Z bonus. You might also insist on a day off afterwards since the team will be burned out after that. Also have in the contract that adding features or bug fixes over X% of normal time will add time to schedule.

You can't change the time, only take out features.

Answer 16

I've seen a lot of this negative, positional division in my career and I think the best way work with it is be as honest and transparent as possible. (Negative phrases like "behaviour is stupid", "have no clue", "cannot be done" should be avoided. Look for solutions/root causes.)

First, it looks like everyone is employing positional bargaining (book). They want what they want and you want what you want.But what is really driving that? Look at what drives their position and target that. E.g. sales just wants to get the product out as quickly as possible to make more sales and help the company's profits. What's wrong with that? And from your side you simply want to make the best quality software you can. So you just need to find a middle ground. I think the best way to do this is education, honesty and transparency. Treat them as part of your team and not "us vs. them".

Agile and Scrum methods try to incorporate this into the entire process. Certain aspects of Scrum take care of this nicely:

1. A product owner that prioritizes features and chooses what goes in each sprint. This person is part of the team. This should be a person that has the clients' best intentions in mind. e.g. this could be a sales person or supervisor. They are involved on a regular basis in deciding what goes into the product so there's great motivation and responsibility (they'll learn to NOT push for time vs quality/features)
2. Any stakeholders are team members as well, they just don't get control in the the backlog/sprints/timeline. Treat them as such and they can learn how estimates are calculated and the inherit complexity behind software development.
3. A scrum master works at improving the process over time. It's not expected to be instantly scrum as that is unreasonable in any situation. They work at removing roadblocks for all team members (and the company).

In summary, just be honest, positive and try to educate - it will eventually improve. Even if you don't officially follow agile/scrum, read some literature to get a better understanding of these concepts and motivations.

Answer 17

Another approach would be to make it impossible for them not to see WHY/HOW you're giving the estimates.

Since you are responsible for the development process, why don't you track the team velocity and show them, based on your past iterations, why you won't make their deadline? I think it is simple: "our current speed is X, and we have Y story points for this iteration".