OK, you’ve done your homework and your application is filled with different usability features. The design is clean, all controls are set properly, tab order and keyboard shortcuts are double-checked. And when you look at the way fresh users approach the application you’re confused.

They don’t use all that stuff.

They don’t because they don’t know how. You haven’t taught them. While they work with the app they’ll step through learning curve – they’ll learn more and more how to exploit better the softer they use. Your task is to make learning curve possibly narrow.

Some things will come with time. If button placement is consistent I’ll expect the same function buttons (like save, cancel, delete) always in the same place. Some things you have to teach. Show which keyboard shortcut leads to which function. As an example quite a good work is done in new MS Office which displays letters on each button after shortcut was used to change tab.


You can throw in some advices like “you can easier do this using that” but my opinion is “tip of the day” method doesn’t work well. You should rather put them somewhere on the screen but in a way they don’t hit the eyes and don’t waste precious working space. This is done nicely in Google Reader where last Google Reader Team Blog post is displayed at the end of the home screen.

There are many ways to improve learning curve. All you need to do is to remember to help your users to learn your world-changing app.

Whole usability issues series.

I spend a lot of time with project managers. Heck, I sit with 4 of them in a room. I want it or not I see how they manage their projects and their project teams. I see how they talk with people.

Each of them does it differently. However there’s one thing which is common – there’s a distance between a PM and the rest of a team. People consider PM as a kind of boss. That has of course a bit of truth since PM is the person who manages the project and at least partially the project team. There’s another reason too. PM is usually a person connecting project team with a client, so he should know what client wants.

Now, PM can use this “power” to get what he wants. Change this interface because it has to be like that. Add this feature because it is crucial for the client. It won’t be accepted during tests. We have to do it different way because business requirements say so.

Each PM sometimes will go that way. Sometimes it’s just easier. Sometimes they don’t see any other way to get what they need.

My advice is: avoid that whenever you can.

If you’re a PM you probably have more knowledge about project than any single person in the team. But it doesn’t mean you always know better. It doesn’t mean you have more knowledge than all your team gathered in one place.

There’s a bunch of better options:

• Discuss. Tell why you think client won’t agree. Go deeper in the discussion. Today we went from trying to decide what columns we should add in the database to description how small vendors should craft their business offers for big clients. It happened during technical session with developers and I don’t consider that time as wasted.

• Listen. We tend to listen to only those arguments which support our opinion. When our position is stronger than our adversary it’s even easier. It’s more difficult to listen to others’ arguments and be ready to change one’s mind.

• Ask. With the distance PM has with the rest of the team sometimes it’s even hard to get someone’s opinion if you don’t ask. Hey, she runs a project so she knows better, right? Why should I throw in my ideas then?

• Delegate. Some decisions have to be made but it’s not a PM who is the best person to be a decision-maker. Programming details. Tools used in development. Approach to testing. The list is long. When the team expects you’ll have all the answers try to delegate finding some of them on others. When encouraged people will be more creative than you’d expect.

Remember, each time you use “I know it better” approach people will less likely participate in decision making process. You’ll end up in more “I know it better” decisions which are very rarely the best possible option.

Next time you’ll be in the middle of discussion try to:

1. Agree with other party argument when they sound reasonable. At least once.

2. Find new points to support your position when you believe you’re right. At least once.

3. Propose completely new model when you don’t seem to reach consensus. At least once.

4. Stress statements of each party you agree with when you’re an observer. At least once.

5. Look for satisfactory consensus instead of keeping as many own points as possible. Always.

It will help.

Your application has shortcuts. Every piece of software has some. Ctrl+S when you want to save something. Ctrl+O to open something. Ctrl+I to turn on italics or Alt+R,S to run spellchecker in my word processor.

Sure, no one knows all of them but every time people start using specific function very often they try to do it a bit faster. They won’t be moving their mouse lightning-fast so they start to use shortcuts.

If the application has some.

Shortcuts are not for fresh users. They are for users who know what they want to do and how to do it. As far as you care for experienced users too you should double check if all your functions are accessible via keyboard shortcuts.

That’s the same kind of situation as with tab order – with low effort you avoid frustrating your users.

Whole usability issues series.

Steve McConnell brings his opinion about agile software development. The message which is delivered is simple: agile isn’t the answer for all questions, sometimes it works well sometimes it does not.

I think one point clearly shows why agile isn’t always appropriate:

“Some businesses value agility, but many businesses value predictability more than they value the ability to change direction quickly. For those businesses, becoming more Agile is a second level consideration; the first level consideration is how to become more predictable.”

If you deliver software for mobile operators or other big organizations you should be familiar with that one. In their ideal world everything is delivered as it was stated in the order: on time and within functionality. They know they will have to pay additional fee for changes which came out during implementation and they’re OK with that. It would be much bigger problem if they were sure all changes will be implemented in the project but it would be hard to say when exactly the project will be finished within ever-changing scope.

For them agile isn’t the answer.

I used to say I hate negotiations. I always considered myself as rather poor negotiator. Lately I had several occasions to negotiate different things. And I have to say it brought me some fun.

The way I exercise the task seems to be non-standard for people who makes their living negotiating, e.g. salespeople I know. I follow several rules.

1. Be ready to leave negotiations without setting the deal. Whenever you’re determined to reach consensus at all costs it’ll cost you much. I’ll always try to sit behind the table with two possible options at the end of the process: success or failure.

2. Try to put yourself in other party shoes. Quite typical approach to negotiations is to look from a perspective of your own nose and then to move slowly step by step until your position is acceptable for the other side. I don’t agree. I prefer to look for win-win scenarios from the very beginning. Unless you look at the proposal with the eyes of the other party it’s very hard to judge its value for people you negotiate with.

3. Don’t waste the time. Yes, I know it is said the time pressure is an enemy of a negotiator. I believe in different approach. If your points are written in the stone – show it. You don’t necessarily have to start with $2000 if you want to end at $1250. You can start with $1300 and show you aren’t willing to move much. You’ll end up having more time on other things.

4. Set own goals. Once I had a chance to ask my fellow negotiator what’s his goal. “I don’t know” wasn’t the kind of answer I expected. I always try to set my goal at reasonable level and it is fine for me when I reach it. I don’t try to push further until the other party brakes negotiations or reject to change any point. And yes, I know that my approach results with some contracts which could be improved a bit. But yes, I’m happy that way.

5. Avoid unreasonable offers. If you’re a seasoned negotiator you’ve seen that a lot – offers which you know isn’t acceptable but is shown as a “negotiating position” or “opening position”. Avoid that. If you’re lucky it can result in lengthening the process, but the other party can feel like they were slapped in the face too. Unless you’re trying to insult people on the other side of the table or you love to waste time it isn’t the greatest idea.

6. Be well-prepared. If you can be caught on the numbers you aren’t well-prepared. You should always know which numbers you show, how you’ve come to them and why you think they’re reasonable. That way even when situation changes you can always recalculate your offer on the fly.

7. Call for a brake whenever it seems you don’t move further. It doesn’t hurt. It doesn’t weaken your negotiating position. It doesn’t moves you back. It gives you a chance to restate your goals or rethink your argument. If you’re a part of a team it gives you a chance to make ad-hoc adjustments in your strategy.

8. Be honest. I don’t see a point in presenting some fake goals or pretending to put an offer you know you’ll adjust soon or to show different reasoning than it really is. Being honest during negotiations builds your reputation and strengthens offers you put on the table. It also gives other party better understanding of your point of view. Beating about the bush is somehow expected but gives you (almost) nothing.

9. Be constructive. Sometimes it can be clearly seen you can’t reach consensus with assumptions both sides have made. If you keep repeating your arguments you don’t move further. However you can try to look for a completely different model which will give you some area where you can meet.

10. Prioritize your goals. If something is really important try to agree on that point and then to move to other ones. Usually you have a number of different parameters which are connected with each other. Sometimes much more important than a price is a schedule. Remember, usually different parameters will be pointed as the most import by each party so it can be fairly easy to reach consensus.

Don’t treat it as top 10 sure-shot negotiating techniques although for me they work fine. Although it isn’t standard negotiating approach it shortens the process and brings me satisfaction with results I achieve. I can hardly stand several standard negotiating techniques which make me boiling because of time wasting. You don’t get a prize for a number of hours you’ve spent on the process.

I haven’t pushed it because I didn’t know it was important.

I’d call if I knew it was a high priority task.

Wasn’t I expected to complete other things earlier?

No one told me it has to be done by Monday.

And so on.

Consequences can differ. Maybe a couple of hours of delay if the task is on the critical path. Or lost deal if someone failed to prepare the offer on time.

The question is:

Do all of team members know how important is the task?

The answer is:

Most likely, they don’t.

When you talk about top priority tasks it’s not enough to tell it at a team meeting. It’s not enough to state it at the beginning of a project. It’s not enough when a project manager knows it. It should be repeated until people know they could call their CEO at midnight to tell him when something went wrong.

Does your team know what’s important? All of them?

This one can be a bit controversial. I believe in simple design. That way user is a somewhat forced to go into most important options/functions which are displayed at the screen.

Sure, most of applications have more functionalities than simple search button, but still it is possible to fill the space with clean working area hiding most of options behind toolbar or menus. I think web browsers are quite good at it. Main area filled with web content, tabs boosting application usability, toolbar with 5 buttons and 2 edit boxes and menus hiding all the rest.

The other approach is to put it all on the sight. Take typical news portal. A number of lists with different content, a growing number of ads, blinking background, pictures etc. All the crap is there and suddenly you can’t find your favorite column. It’s always tempting for marketing to put as much as possible on the starting screen to show all the features of the app.
I don’t buy that. I believe the clean design is much more useful. However like I’ve said there are different opinions about this one.

Whole usability issues series.

Our beloved marketing team in Wind Mobile found very interesting news lately. MarketingSherpa published a poll which shows why customers decide to leave vendors and which reasons are pointed by vendors in the same situation.


Two main conclusions:

Customers leave because they’re not happy with service they got.

Vendors know nothing about real reasons for losing their customers.

The poll shows what I always believed was important: the quality. It doesn’t bring an easy profit to salespeople since you need additional costs to achieve high quality. It isn’t a piece of cake for tech people either since you need to put additional effort to whatever you do and generally care more. Yet somehow, people on the other side are able to appreciate that.

You can say maintenance team doesn’t decide which vendor will be chosen. You can say the next project will be delivered to a different project team. You can say the price is the only factor.

Bullshit.

Maintenance team doesn’t decide, but is asked for an opinion. Project teams communicate between each other and they actually know what the current vendor rating is across the company. Price is never the only or the most important factor in IT. Customers always weigh functionality, level of fantasizing, track record and actual content of the offer. At the end of the day it’s easier to negotiate the price than a track record. You know, the latter won’t change just because someone says so.

The price is rarely the only matter of making important decisions, although I know situations when it plays the main role. But even then differences must be significant to counterbalance other factors.

Even when your salespeople tell you a different story.

If you asked your users how your application should work how they would answer? I guess:

Like our good old app, but better.

The flow of operations shouldn’t differ much. Placement of often used functions should be similar. Shortcuts should be connected with the same operations.

If you have some kind of industry standard application in your area, don’t hesitate to base on that one. If not, well, look for those applications you want to compete with.

Remember you most likely don’t bring something totally innovative which can’t be compared with any other software being on market for some time. Remember people like what they know or rather people feel comfortable with what they know. And making your users uncomfortable doesn’t make user experience skyrockets.

Whole usability issues series.

I have a small exercise for you. Describe several attributes of a great team.

Dedicated people?

“One for all, all for one” type of attitude?

Friendly atmosphere?

Being helpful to each other?

Focus on achieving team goals, not personal ones?

Strong personal relationships beside professional interactions?

Ability to deal with difficult situations?

I guess all of them are true. The funny thing is those attributes are exposed more likely whenever tough times come. I know several great teams which were born when no favorable circumstances could be found.

A team with commonly disliked boss. Suddenly it appeared the team wanted to show not only they can manage their task with no boss at all, but even with a boss who disturb instead of help. Engagement skyrocketed. Teamwork went on new level. They used to say the sky was the limit. They should just leave but instead they choose to resist. What an irony, soon after they got what they wanted to – their boss had left – the team scattered.

A technical team which worked in difficult company environment. All decisions were driven by salespeople with no balance from the other side of the barricade. Unreasonable project decisions were their bread and butter. No one tried to understand all the technical issues. Schedules were cut in the half with no rational reason. If you add some financial problems of the company the environment should force anyone to leave immediately. Another time people chose to fight. Despite tough time they managed to complete very challenging task. They built strong personal relationships. They created friendly oasis in hostile environment. However, since things haven’t changed for a longer period of time they started to look for a better future elsewhere.

Becoming a great team is a way of self-defense. If people acted as they’d do during peace time they’d have to leave soon. Leaving a job is almost always a hard decision to make so people start to be engaged a bit more. And a bit more. And a bit more... Other try to follow and suddenly everyone works as he was on steroids.

A bad news for those companies which try to forge great team that way is you never know when it ends. Patience isn’t endless. People will leave and you’ll lose much more than you’d thought – an additional value brought by their greatness.

Building a great team during normal time can be paradoxically more difficult, however that way the results last much, much more.

There are two kinds of users. Those who want to understand how the darn thing works up front before they start playing with the application and those who expect to start the darn work as soon as possible.

For the latter vendors prepare sometimes something like a quick start scenario. Some predefined settings which allow avoiding long and dull configuration process. Computer games are a great example. Very often you can choose to set every detail of your character/team/environment by yourself or you can choose among one of predefined sets.

There are great examples in different areas too. Our financial and accounting application has test database installed by default. People can check how it works on test data without affecting production database.

Of course quick starts aren’t applicable in every application – usually they are useful whenever some pre-configuration must be made by the user. However this kind of approach you can find even in Internet Explorer with predefined list of favorites.

Whole usability issues series.

It’s easy to criticize others work.
It’s hard to be fair yet critical when it comes to judging own work.

It’s easy to point others failures.
It’s hard to admit own failure.

It’s easy to over-interpret others points in discussion.
It’s hard to say sorry when you go too far with your judgments.

It’s easy to work from this point to that point.
It’s hard to look always for a broader perspective.

It’s easy to become angry when things go wrong.
It’s hard to overcome angriness and look for constructive solutions when things go wrong.

It’s easy to look for excuses.
It’s hard to look for solutions.

It’s easy to say.
It’s hard to do.

It’s easy to say “no.”
It’s hard to look for a compromise.

Just a reminder. Mainly for myself.

Open your application. Start hitting Tab on your keyboard. Look where focus goes. Is order intuitive or random? Are all controls accessible?

Try to fill in form in your application. Go through edit boxes, check boxes and radio buttons with Tab. Can you get to another control you are expected to fill with one Tab press? Each time?

Setting correct tab order is a small, yet dull, development task. You don’t gain much completing the task. On the other hand you lose much if you reject to set the tab order properly. Your users get frustrated with the product. User experience peaks down. Everyone starts using competitor’s software. Your company bankrupts... OK, I went too far with that one. However that’s another small thing usability is built from.

Whole usability issues series.

The other day I wrote about setting rules and things which usually need to be done to have new arrangements working. However you’ll see some of your Great Ideas which you’ve implemented in the work environment don’t look as great as they appeared at the beginning.

What to do? Run in panic? No, not so clever. Pretend it’s all OK? Well, at least that way you don’t admit you’ve failed, but I wouldn’t say it’s worth to add everyone another dull task just to show you aren’t so great as you’d like to be. Change the rule? Oh yes, of course!

If something doesn’t work in your house you either fix it or throw it away. Why shouldn’t you do the same with processes in your work? Don’t force people to do unnecessary work or they’ll force you to look for replacements. It’s a fair deal, isn’t it?

And no, your reputation among team won’t be harmed. Quite the opposite.

Few days ago Ray White with his post about buying versus building software components reminded me my very first post on the blog which touched the same subject.

Over a couple of years I’d add one more thing to the discussion. Remember what your core business is. Sometimes you can judge building software just for yourself basing on functional comparison and cost analysis. However before making a decision go deeper.

Think if that would bring your company forward? How much effort you’ll need to maintain that piece of software. How many projects you won’t be able to handle because of building software tools inside. What’s the alternative cost?

I think over time I evolve more into “leave it to professionals” kind of approach. What is yours?

Make your application looking nice. I don’t say every app has to be shiny and polished like Vista, but make it looking good enough for your users. If you write for system administrators then console should be enough. But if you do anything more, even when your UI can look ugly don't make it sloppy. Controls set straight. Buttons placed intuitively on each window. Toolbars don’t changing their appearance randomly. All controls and options accessible with keyboard.

You get much with little effort.

Whole usability issues series.

You’ve heard that probably.

“Your projects are usually late. Do something about that. We lose credibility in the eyes of our customers.”

Ouch.

“And another thing. Last schedules you’ve prepared are unacceptable. They should be cut at least by a half.”

And now you’re confused.

“Sure, feel free to cut deadlines by 50% and yes, this time we’ll deliver on time.”

Except of that’s not true.

To be honest I always feel uneasy when I have to deal with those kinds of situations. Yes, I understand so called business perspective. I actually can imagine that a couple of months of schedule can be unacceptable for a customer. I know that easier or more appropriate solution from the technical perspective can be rather not suitable business-wise. However at the end of the day you need to deliver. Hopefully something within scope, time and budget.

There is no easy answer how project manager can discuss those accusations. Several things can help however.

1. Make your estimates as reliable as you can. Create something what you believe can be achieved. It’ll be easier to discuss that later on.

2. Look for a compromise. A couple of man-months of development can be covered differently with different resources. You need different buffers for a newbie than for a veteran member of the team.

3. Remember about your environment. Estimates shouldn’t be done for veterans when you don’t have any in your team. If you have a number of other projects to do don’t consider there are none.

4. Be assertive. When something isn’t reasonable, point it. When something can’t be done, explain why your team isn’t capable of doing that. Describe what needs to be done if you are expected to achieve that goal. More experienced team? Some training maybe?

5. Talk about merits. Don’t start “it is so because I say so” type of discussion. It’s a dead-end. Think. Were past estimates good? Where you made mistakes? Why? Is that similar situation in any way?

6. Admit where you failed. Don’t try to play the hero because most likely you’re not. Most likely at least several of your estimates were wrong. Don’t try to hide that. Try to name reasons why it happened so. If it don’t help with the current discussion at least you look more credible with that.

And remember one thing: it isn’t a win-lose only scenario. You can end with win-win or lose-lose too. The former should be your goal.

Now you’re a manager and you have some power. Now you’ll show them. You’ll set up The Rule.

Of course we all know The Rule is reasonable and will be an improvement. You do it because you believe it’ll help, not just to show you have the power.

You announce The Rule to all interested parties and that day you go to bed with great feeling. You did something. Everything will be better now.

Then Mr. Reality comes to kick you in the ass. No one cares about The Rule. Everyone works exactly the same as before. Don’t they see it would all be better if they obeyed?

Most likely they don’t. At least not all of them. Not everyone will be convinced by your words, they expect to see results. And they won’t see results unless they start to obey The Rule. We have a deadlock here.

The thing you need to do is to check regularly how people deal with The Rule. Remind them they should do what they are asked for. Tell them once again why The Rule was invited. Hopefully after several iterations everyone will treat it as a natural part of their workplace and you’ll no longer need to think about that.

Which features are the most important? For salespeople newest ones. For marketing your application differentiators. For developers those which bring interesting problems to solve. Unfortunately usually none of them actually eat their own dog food. And for users the most important features are those which are used the most frequently.

If you need or want to work on usability focus on those functions. It can be search and time you need to wait to see first results (first 10, not all 16,9 million of matching results). It can be filing an invoice for simple invoicing application (what a surprise). It can be writing or test formatting for word processor. You name it. It’s your software.

Checks how accessible are those features. Measure how fast they response. Verify if they are easy to use. Think how intuitive for a new user they’ll be. Focus only on features which are used the most often. When you have no ideas how to improve them move to next, a bit less frequently used.

Whole usability issues series.

The other day I had a chat with one of my friends. He told me one thing.

There’s nothing more demotivating than being helpless. You only frustrate yourself.

We were talking about taking responsibility for a part of the company as a chance to deal with issues which annoyed us. We considered that as a chance to do something about that instead of ranting about the situation. But there is another perspective.

It doesn’t matter if you’re manager or tester – there will be thing which you don’t like and you don’t want to accept them in the long run. It can be atmosphere of the workplace, it can be lack of order in project management, it can be constant context switching, it can be beef-head boss, it can be anything.

Now, you either see you’re able to change the annoying issue or you end up as frustrated employee and eventually leave. Yes, usually managers have more tools to change the environment they work in, but the rule is general. If a developer can’t go through with his great ideas how to improve development his frustration will rise. If a project manager is struggling to move her projects a bit from the complete chaos with no effects she won’t be happy with her job.

If you’re a manager you have to give your people chances to change their workplace. The place they work in and the way they work. It doesn’t automatically mean you have to agree with each idea, but if you listen you’ll hear a lot of reasonable ones. Except of improving performance of your team you’ll also limit their frustrations.

You take this new app which is told to be better than the one you use at the moment. If you’re lucky it’s intuitive and you don’t have any problems to set it up. Then you start working. And it hits you. Important operations are slow. Not dramatically slow, but significantly slower than with the old app.

Take new shiny Vista box with new shiny Office 2007 and sometimes it’ll freeze for a second. Annoying. Your good old XP with Office 2003 didn’t perform like that. Take Google Spreadsheet try to cut and paste a piece of cells. What the heck is happening? Am I faster than the app? Oh, yes I am. It wouldn’t happen with good old Excel.

The clue here is responsiveness. How fast application will answer to most often executed operations. Lightning fast? Maybe as fast as industry standard? Or you’re just too slow?

This is the big issue especially for web applications. Responsiveness of the web is significantly worse than desktop application. As far as we used WWW just to browse websites it was natural since it wasn’t a replacement for an existing application but a completely new one. With financial, CRM, project management or office apps we’re trying to replace desktop software we use every day. If they’re slower the user experience descriptions will definitely use the word “frustration.”

Focus on your software responsiveness, especially on the most important functionalities. Compare to other, legacy software in your market. If you’re significantly slower, well, that’s a sign you have a task to do: improve.

Whole usability issues series.

I was writing here about usability of applications on a couple of occasions. And since usability is made of small things I thought it’s a great idea to run another series of short posts on the subject.

There will be post per week published unless I’m off on vacations or some disaster happens.

Usability issues so far:

Responsiveness
Most frequent used means most important
Nice enough
Tab order
Quick start
Like good old app
Clean design
Shortcuts
Learning curve

There are at least two answers to the question whether functional specifications are useful or not. Agilists would say specifications value is low since software will be changing significantly during iterations. The other party doesn’t even start a project without singed detailed functional specification.

I think both sides are right. Sometimes. It depends on client you work with. If you have a good partner to employ agile approach and you value this technique, go for it. As far as you are able to find a consensus with your client you won’t need detailed specification up front. Probably some documentations at the end of the process will be enough.

On the other hand there are customers out there who will exploit lack of defined functionality range to switch into feature creep mode. There will be a lot of new critical functions created on the fly. There will be a lot of interpretations how different things should work. Your only shield is anything which was formally agreed before. Possibly functional specification signed along with the agreement.

Actually it’s neither the size nor the type of the project which plays the main role here. Not even your software development and project management methodologies. The client is important. Let’s take a typical implementation for mobile operator (things I deal with every day). Project timeframe between 6 and 12 months. With the same system, similar scale and two different customers we need two approaches.

One client sets us a list of goals and work actively with us during development. We don’t even try to create detailed description of developed features and we expect a number of changes when they see first result of our work. Since client attitude is reasonable and they don’t bring things completely out of agreed scope it works fine.

Another client brings very strict verification phase when a number of new “improvement ideas” are submitted as bugs. As far as we don’t have detailed scope of work there will be some interpretations how different features should work. And since the requirements are changing over time (which is fairly natural) no specification means feature creep. A feature creep invited on the very late stage of the project which blows the schedule up.

Since I could say which style I prefer it doesn’t really matter. What matters is which style is preferred by our beloved clients. We can adjust ourselves. But the answer to the question from the title will remain the same: it depends.

You could have heard that several times.

How much time it will take to complete that?

Two months. But we can’t complete that project in two months from now.

Why? Isn’t that just a matter of resources?

No it’s not. Whole core team is at the moment fully engaged in other project and we’d need at least two of them here.

Let’s take two of them then.

OK, but consider the other project as late by half of the year. Fair enough?

No. Can’t you find other people to do job?

Yes I can. I will have them in the office in 2-3 moths. And after another half of the year they’ll be ready to undertake the task...

Resources (what a “great” name for people) are almost never time independent. When you talk about a team, they probably have work planned for next several months. Sure, you can go, change their priorities but you should always consider alternative cost of doing that.

It’s not only people’s work which costs you money. There are other commitments also. Commitments your salespeople have already cashed in their income forecasts. Commitments you’d have to break if you took some people out to other tasks. With all consequences. Consider those broken commitments as your additional cost. Alternative cost of focusing on something else.

Now you have the full picture. And full cost of telling the customer it’ll be done in a couple of months.

By the way: you’re really lucky if your salespeople understand this concept. Personally I’m lucky enough to work with really reasonable sales team. They do understand.