

How I Under-promised, Over-delivered and Screwed Myself - boyter
http://nathanconyngham.com/under-promising-over-delivering-screwed-me/

======
jmduke
A better title:

"How I didn't know how to under-promise."

I did freelance web design in high school (nothing fancy, HTML/CSS with stuff
that clients thought was fancy in 2006, like Lightbox and RSS) and after my
second client, where a five-page photography portfolio turned into a
Frankenstein's monster of a PHP web-app held together by duct tape and invalid
code, I realized two things:

1\. There is never such a thing as being too specific.

2\. Bill hourly.

~~~
tptacek
You mean "bill time & materials". Hourly is just one way to do that, and it's
an especially painful and counterproductive way.

~~~
mh-
I agree. I think the relatively-green consultants here would get some value
out of you expanding on how T&M can work for them.

~~~
porker
I certainly would. Even after 7 years of successful work, I've still not got
billing sorted.

Fixed-price jobs generally take double the time (losing me half); sprints work
if the client understands and is in charge of the project, but most see it as
a cost-sink and nothing will be delivered without extorting extra cash (which
a long-time fixed-price client spat at me last week...).

~~~
otoburb
Fixed price bids are better when you've already established a working
relationship with your buyer. A good way to establish a working relationship
is by starting off fixed-price if the scope is narrow enough and explaining
that T&M is more likely to be more expensive for the buyer based on the scope.

Usually this results in the buyer either:

(i) asking for a lower price;

(ii) disagreeing with the FP bid and going T&M;

(iii) walking away.

The basic assumption is that scope is narrowly enough defined. If it isn't,
then try hard to narrow the scope and give the deal 1 to 3 hrs for this
exercise (depending on your available hours classified for business
development aka "biz dev"). At this point, hopefully you've got the
requirements narrow enough that you can then engage in the exercise above
after coming up with an estimate or quote.

If (i), then roughly itemize and remove items to bring the price down to
change the value proposition. Avoid keeping scope the same and bringing price
down, or else this is a plain discount pure and simple and hurts you down the
road.

If (ii), then the follow-up move for future deals with the same buyer is to
clearly show why their final T&M billables could have been cheaper if they'd
gone with FP.

If (iii), count yourself lucky. Nothing harder than letting business go until
you get yourself into a deal where your costs are higher than revenue (aka.
negative margin deal).

>>Fixed-price jobs generally take double the time (losing me half)

... that sentence implies a pattern of failed FP deals and lack of scope.
However, I am empathetic because other clients have stated that they are
uncomfortable with code sprints on a professional services basis solely
because of the lack of concrete deliverables that can be used as payment
milestones or triggers.

Code sprints are better off billed on a T&M basis unless, as you say, the
client _really_ understands what they're doing. In most cases, buyers don't
know what they want, which is why some time must be spent on building on biz
dev building the pipeline.

~~~
porker
Thanks. I appreciate this.

Could you define T&M in this context? How does it differ from code sprints?

> If (ii), then the follow-up move for future deals with the same buyer is to
> clearly show why their final T&M billables could have been cheaper if they'd
> gone with FP.

I understand (i) and (iii), but why is showing them FP is better than T&M a
good idea? Isn't T&M more profitable for me?

> ... that sentence implies a pattern of failed FP deals and lack of scope.

That's accurate unfortunately. There's always scope, but for sub-£2k jobs (and
worse for sub-£1k) there's a trade-off between time spent tying down the scope
and time doing the job. If I spend an hour on it, that's 5-10% of the overall
budget gone.

~~~
otoburb
T&M is "Time & Materials", which is the same as billing by the hour or week.
The advantage of T&M for code sprints is because of the typically ambiguous
and uncertain nature of the sprints. Even though there's supposed to be a well
defined and constantly prioritized queue of features to be completed during
each sprint, the fact that they can be changed and moved around means it's
incredibly difficult to nail down an actual deliverable beyond a vague
"payment of milestone X due upon completion of code sprint", which is really
no different than a duration-based payment schedule which basically boils down
to T&M :D

FP is generally (not always) better for both the buyer and provider because:

1\. Buyer benefit: For a given scope there is a corresponding, known budget.
Typically, fixed/forecasted budgets are preferred by buyers so they can
forecast and set internal expectations.

2\. Seller benefits:

(i) If it's a task that you feel can be done quickly or with less effort than
normal (e.g. done repeatedly for others in the past), you can still charge
based on the VALUE of the work vs. the # LABOUR UNITS, ultimately resulting in
a higher margin for the seller with a tightly scoped budget for the buyer,
_even though it takes you less time to complete_. The only time you need to
consider lowering list prices for work done several times in a row is when a
perception of commoditization creeps in, either by the general industry or
(more likely) by the customer(s).

(ii) T&M is more profitable for you in the short term, but often causes more
overhead and problems for the buyer on larger deals as scope uncertainty and
ambiguity increases. Typically, the easier you make your buyer's life in terms
of reducing overhead and paperwork, the more likely they are to want to work
with you in the future.

>>There's always scope, but for sub-£2k jobs (and worse for sub-£1k) there's a
trade-off between time spent tying down the scope and time doing the job.

Sounds like you're an independent freelancer. In this instance, you're in a
tough spot. I suggest putting in 1.5hrs that you swallow from a cost basis
with a firm goal to minimize potential risks during the engagement.

The worst part of being an independent is that your overhead is typically
higher if you try to go the FP route for higher-valued deals as you are solely
responsible for writing the SOWs, thinking about the timelines, managing the
customer AND delivering. I can absolutely understand why, in that situation,
you're comparative advantage is defaulting with T&M in most situations and
hopefully raising your prices a bit to compensate for the inevitable pre-sales
discussions you need to have with potential customers.

Sorry I can't give more advice there. I've found patio111's posts to be very
informative for independents looking to grow.

------
nrivadeneira
I think Nathan's got the meaning of the phrase mixed up. The idea isn't to
promise your standard output and then run yourself into the ground trying to
exceed that. The "under-promise" part means that you promise less than what
you know you can deliver. Having done that, you deliver your standard output
and thus have "over-delivered". In this manner, it's sustainable.

~~~
mistercow
The trouble with actually under-promising on a project is that unless you have
actually done almost that _exact_ project in the past, or are a _fantastic_
pessimist, you will fail to under-promise. See
[http://lesswrong.com/lw/jg/planning_fallacy/](http://lesswrong.com/lw/jg/planning_fallacy/)

~~~
habitue
Which is why you're under-promising. So that when inevitably things don't go
as well as planned, you have a buffer.

~~~
georgemcbay
Hofstadter's Law: It always takes longer than you expect, even when you take
into account Hofstadter's Law.

------
gnarbarian
I did this on my first real consulting gig on a state contract. We were on a
roll kicking ass working 10-12 hour days and we blew through the requirements
in the first deliverable a month early. When you're going like that you don't
want to stop.

Rather than taking it in and showing them. The lead decided that we should
just start in on the second deliverable.

We busted out most of the work there before the meeting began regarding the
first deliverable.

When we went in to the meeting we were shocked to see that everyone who had
written up the requirements had quit and moved on to other jobs. The task had
fallen to other employees who wanted to completely change the direction of the
application. While the first deliverable did not change. All the work we had
done on the second was worthless.

After that I never again worked 12 hour days while on schedule and I never
again did anything ahead of schedule that wasn't a 100% sure thing.

~~~
otoburb
It would have been fine to get the first deliverable done early. I'm confused
why the lead (or whoever was responsible for invoicing and managing the
customer relationship) didn't invoice right away.

The team still could have gone ahead with the second deliverable "at-risk"
(i.e. on the _assumption_ that the customer still wants the next deliverable).
The key failure point here was the touchpoint with the customer and the
invoicing. If there was no payment trigger/invoice for the first deliverable,
that only emphasizes the importance of the customer checkpoint.

Usually, the project manager (sometimes known as the engagement manager in
other shops) is responsible for this. That person failed the buyer, your
organization, and your team.

~~~
gnarbarian
I don't really understand why it went down like that either. It was the
lead/PMs first job with the company and mine too. He may have been concerned
with losing face or he wanted to finish the whole project super early and
possibly get a bonus because it was fixed bid.

The requirements doc was extremely clear and robust. We felt confident that we
were on the right track. Regardless I pestered him to schedule a meeting right
away. After two weeks he relented but it took us another two weeks just to get
in there due to people leaving at the state, general confusion over there and
I assume them spending time rewriting the second deliverable.

There are a number of things we could have done to avoid the grief on our end.

1) We definitely should have made a greater effort to get in there as soon as
we were done with the first deliverable.

2) we could have not burned ourselves out working 12s in the first place on
salary and finished about at the right time when they were ready for us.

3) After finishing early we could have taken the equivalent time off instead
of trying to power through the second deliverable. (not getting ahead of
ourselves or burning us out)

We ultimately delivered the project within the time constraints of the
estimate (a miracle considering we lost almost a month). although not
including the OT we spent initially. So the client was happy but our team's
morale never quite recovered.

------
Aqueous
To sum up: just promise what you can deliver, deliver what you can deliver,
and stop playing games.

Honestly, I've found that the value of even simple web applications in modern
business is so enormous that once you have your foot in the door in a place
the contracts just dont stop coming. Especially when you were intelligent
enough early on to be selling them an ecosystem, a complete automated solution
to their problems, instead of a single, one-off application. The price of
going out and developing a good relationship another contractor who is capable
enough to understand your existing code becomes prohibitively high, especially
when they already have a good working relationship with you.

Is this cynical? No. I'm not suggesting that you slack off or deliver
substandard products. I am making an accurate statement about the value of IT
in the marketplace. It just reflects the business reality of the moment:
people who can make applications are still rare, these applications are
immensely valuable to businesses, and if you can do them, there will be
someone to pay you to do so.

When competition becomes steeper you can start to play games with
expectations. Until then, never let the company intimidate you into thinking
they're doing you a favor by giving you a longer deadline. You're doing them a
favor, assuming the product works like it should. Deliver and promise exactly
that.

------
otoburb
I love that the OP put this out there as a learning experience. Regardless of
the fact that he has an MBA and a technical background, he cheerfully admits
he was wrong and tries to do a better job managing expectations in the future.
I'll provide a blow-by-blow analysis.

>>“We need to under promise and over deliver.”

Great! But, why? There has to be a concrete, preferably measurable, reason(s)
to have this mindset. As other commentators noted, what he did wasn't really
under-promising, but simply adhering to the original schedule, which implies
that the customer was on-board with the agreed timeline.

>>The project moved along and thanks to some long days we actually managed to
deliver functionality ahead of schedule.

What did he expect to get out of this? What did he tell the team to justify
this?

>>We continued our iterations, tuning functionality and consistently over
delivering when the team started to become disgruntled and exhausted.

Even with the right motivation, burnout is a constant issue for services staff
in any industry, especially when the engagement lead doesn't monitor both
sides (customer and internal). He would have monitored this more closely, or
would not even have gone down that path if his internal team were billing him
on an hourly basis, as it would have forced him to more concretely justify to
himself and his partners what he expected to get out the self-imposed
accelerated schedule.

>>To continue to over deliver, the team had been working very long hours,
weekends and some had missed important family appointments.

Live and learn. Seems like you are somewhat charismatic, or have a hold on
your employees that made them put in the long hours and miss family time
without pushing back on you.

>>The next day we presented to the client, they were surprised at what we’d
achieve in such a short time and were happy that we were ahead of schedule.

As engagement manager, you should have ensured that this wasn't a surprise to
the customer! It would have allowed you to more quickly gauge whether (a) it's
worth continuing on the death march and (b) how the customer will react.

>>The discussion turned to the next set of deliverables, the effort and the
expected delivery dates. This is where it all started to fall apart.

No -- we need to be very clear here. Things started to fall apart well before
this due to: (i) lack of identifying value exchange for the death march on the
first deliverable; (ii) lack of continual communication with the customer.

>>“Why can’t you do it? We’re not asking for anything more, it’s actually less
than what you delivered before.”

The standard answer here is:

(i) We can't do it because the first deliverable was a one-off to help you
reduce time-to-market / internal target date, but this second deliverable will
require additional staff that I don't have. From a resourcing perspective, I'm
not going to charge you for the additional hours that my staff spent on the
accelerated schedule for the first deliverable because I made that decision
unilaterally. We must stick to the same duration for the second deliverable.

(ii) I know you're not asking for anything more; that's why we're able to
commit to our originally agreed upon deliverable duration (e.g. 2 weeks), and
nothing shorter.

(iii) If you want us to work weekends, as per the Statement Of Work ("SOW")
that you signed, you'll need to pay for the additional weekend and holiday
staff shifts for the second deliverable [context: sounded like the OP did in
fact have a contract in play, and hopefully had language in the SOW that
covered increase in base rates for weekend & holidays]. We'll swallow the
increase in costs for the first deliverable because we did it of our own
volition.

(iv) I'm glad that we confirm our original agreement regarding the nature,
specificity and scope of the second deliverable (i.e. that it is "less than
what you delivered before"). This further emphasizes that our originally
agreed upon duration for the second deliverable is firm and we can deliver
with the agreed upon duration.

>>Over the next few meetings, with significant effort, the discussions started
to turn around. I had been reborn and now realised:

There's hope for you yet! In most situations, this is where the customer
escalates, goes over your head and tries to get you off the project, or where
the firm partner/general manager tries puts a PIP on your record because your
customer relationship management skills (the number one reason you're
typically chosen to become an engagement manager) was so severely lacking.
Seriously, that was a great turnaround if the OP did that himself.

>>It’s not about the effort, it’s about the outcome. The client did not care
how much effort we’d put in.

In general, this is true. However, as part of your job you are supposed to tie
in the effort with the outcome, whether via narrative, task-based estimate or
simply pure dollar terms. Do this, and your job becomes easier explaining
timelines and pricing deliverables.

>>We needed to become a partner

Yep. However, as part of your job, you must be cognizant when a psychopathic
or aggressive customer has no interest in becoming a partner and only
extracting as much value as possible out of the current deal. Customers can
flip, and engagement managers must always be taking the customer's temperature
to protect the deal, the team, and the deal margin.

>>The expectations had to be reset

As others noted in this thread, they weren't managed properly. OP was fine up
until the kick-off when the baseline timeline was established and agreed upon,
but then went off plan for no compelling reason(s).

>>As painful as this was, it did teach me a lot. Get on top of this before it
blows out.

Amen.

>>Under promising and over delivering is for suckers.

This last sentence is wrong. Forget about under promising. Just focus on the
over-delivering part. Only over-deliver if you have the appropriate risk
appetite, enough deal margin you're willing to sacrifice, and compelling
exchange of value. Examples of exchanges of value are:

(i) "If we make a great impression that is sustainable in the long run, we can
leverage this influential customer for references in the future!" \--> Make
sure your sales team has the balls to follow-through on this. Surprisingly,
many organizations and field teams have a hard time asking for references for
future deals.

(ii) "When we were talking, the customer kept referring to feature X that's
gating the next phase of their program and holding up future deals. If we
deliver a proof of concept showing that we can deliver this functionality, it
might clear the obstacle for future services deals." \--> Make sure your
product/engineering group can deliver, and that your support group will
actually support the new 'feature' that you deliver.

(iii) "The customer is asking us to bring in the schedule. We've got no other
deals on the table and all of our guys would be on the bench (i.e. idle)
otherwise. Let's swallow the cost for a short period of time." \--> Engagement
manager needs to go into 'expectation management' overdrive and find a
narrative that works for both parties.

------
el_fuser
If you had to put in ridiculous hours to hit the _under_ deliver timeline, you
in fact over promised.

~~~
DrStalker
That was my thought too - why did they not put in sane hours and deliver as
promised, instead of killing the team to overdeliver?

------
georgemcbay
This sort of expectation management is also why it is a terrible idea to show
a client a slick UI mockup that kinda works (but is missing the underlying app
logic).

As far as they are concerned, you're pretty much almost done because all the
stuff they will ever see is there and looks good. No matter how much you try
to rationally explain to them that it is just a superficial shell of an app
and is a long way from done, a lot of them just aren't capable of
internalizing this concept meaningfully.

~~~
nknighthb
What's the best way you've found to manage that particular issue? Line-art
slide decks instead of interactive demos?

~~~
georgemcbay
In my experience, yeah that's basically it. If it helps to have an interactive
demo to communicate things, keep it ugly when showing it to the client, and
show them the final UI designs separately as static image files. Even if
you've already done the work to bring the assets into the demo, avoid showing
this to the client as long as is reasonably possible to manage their
expectations because they will almost universally have a hard time separating
the UI/UX functionality completeness from everything else.

Obviously there are situations where the client will, in fact, understand the
distinction, but I assume they won't until proven otherwise.

------
Tloewald
Expectations management is probably the most underrated skill in the world.
(Cough Obama Cough.) The problem isn't the idea of underpromise and
overdeliver, it's not realizing this is about expectations management (it's
also about only thinking of the idea in terms of customers -- your team needs
to be treated well too).

First of all, pad estimates realistically, add contingency estimates, trade
off deliverables against shortened schedules, and then you're in a position to
underpromise and overdeliver and not screw yourself. Oh yeah, and don't
deliver early, ever. Wrong axis to exceed expectations on. Deliver more
features than originally promised, or more polish. Never create expectations
of faster delivery, you shoot yourself in the credibility.

~~~
danmaz74
_Oh yeah, and don 't deliver early, ever. Wrong axis to exceed expectations
on. Deliver more features than originally promised, or more polish._ This is
the most important thing. Under-promise, as much as you can. Get what you
promised done - with normal working hours. IF there is still time, do
something more (a little, nice to have feature, or polish). Deliver on time.

------
adammil
Having hired many software development firms for projects, I expect the
project manager to ensure the consulting team is not working inhumane hours
and to push back if I ask for too much, too soon. Healthy push back should
normally come in the form of "What you want will take an extra developer, an
extra month, an extra $20k, etc." and let me decide if I still want to do it.
If the firm fails, then I fail, so I never intentionally do things to
undermine the consultant, but I am also not perfect and depend on honest
communication from them. Also, a project done ahead of schedule is not as
helpful as it seems. Even if the consultant is done early, it doesn't always
mean that I can start my next milestone early.

~~~
nknighthb
And then when the managers rely on pushback from engineers who don't know how
to say no, they burn out and the whole thing blows up.

I still don't understand how our industry makes any forward progress in the
aggregate.

~~~
levosmetalo
If you are a manager, it is a valuable skill to be able to actually hear "no"
from the developer, which may come in many different flavors, but only a few
will actually say "no" plainly clear.

On the other point, this seems more like a US/India thing. In Europe, where
there are certain regulations about working hours, mobbing, and in general,
higher employee protection by law, people are not that afraid to say "no" like
in the US, but it's still not always clear and loud.

I guess centuries of taking heads from people saying "no" have taken its toll,
and it's still hard to say "no" to superior.

~~~
justinlloyd
35 years has taught me that saying "no" as an engineer means you are being an
"obstructionist" or "not a team player." I am most definitely one of those
because I was taught to say "no" very early on. The problem is that many
people are affronted when they hear "no," take offense to it, possibly because
it is a rejection, or, and this happens more frequently, a "no" answer to a
lot of managers means "I just didn't ask you to do this persuasively enough."

------
mzarate06
_Why can 't you do it? We're not asking for anything more, it's actually less
than what you delivered before._

Don't let a client, or anyone for that matter, corner you w/statements like
that.

Regardless of whether they were right or wrong, in terms of the amount of work
they're asking for being less than the previous, have something to show in
regard to why it's not as simple as they perceive.

For example, consider adopting a thorough estimating strategy, broken down
into small iterations of work. An estimate showing the amount of hours or
calendar days the next iteration would take, accompanied by more realistic
dev-hours-per-week (burn rate), would have been the right way to counter the
client's statement. It's much harder to argue with with supported numbers.

 _My grand plan to under promise and over deliver had led to a disaster!_

Any plan where you take on more work than you can handle in a given time frame
will lead to disaster. Under promising and over delivering had little, if
anything, to do here. This was entirely a management problem (dev schedule,
client expectations, etc.).

------
soemarko
> It started with an internal meeting that focused on the expectations set and
> how we were going to now deliver. That’s when it happened. I blurted those
> horrible words out. “We need to under promise and over deliver.”

Dude, those are the words to live by. Not marketing spiel. By saying it to the
client you did the exact opposite. You over promised.

------
entangld
There are lots of different types of clients. Some use your response to their
first request as a measure of your standard output. Once that is known, a
difficult client might continue to demand more.

I've found this happens often with clients who are the least knowledgable in
your area of expertise. Sometimes their insecurity compels them to avoid
getting screwed, by making sure they're getting everything they can out of
you.

Other clients, with lower expectations, might be overjoyed by the the same
efforts. All clients are not equal.

------
dossy
tl;dr: OP failed to under-promise correctly.

------
stfu
One think I learned from these type of situations is that it is important with
some clients to stretch how difficult the project is and keep a constant flow
of signals that show the hard work we put into the projects. In my perspective
everything is super difficult. Unless the client knows that it is super
difficult then it must look really easy. But it is a very nuanced approach,
not that black and white as I describe it.

The client must take away the feeling of "they moved heaven and earth for me
and I really can't expect them to pull such inhumane hours for me next time"
and not "well, they clearly can do a lot more if I just challenge them a bit
more". It depends a lot on the client relationship and the related
communication.

~~~
yaddayadda
I recently had a waitress who "moved heaven and earth for me" (that's the
phrase she used over and over and over again and again and again). I don't
doubt that she got the cook to do a favor for me, but hitting me over the head
with it until she was blue in the face actually made me lower my tip.

As in all things, there's a balance - having the client understand that it
wasn't a cake walk is important, but not beating them over the head with it is
important too.

------
ojbyrne
Over-deliver doesn't mean "deliver early." It means deliver better quality.

------
jrockway
Because if you let a software deadline slip, you'll be the first person to
ever do so...

(I like the whooshing sound they make as they fly by.)

------
sakura_k
If you had to pressure your team to over-deliver against the first under-
promise milestone, you completely failed Project Management 101. The point of
"under promise, over deliver" is to give your customer a risk-realistic
timeline that you can likely exceed, but which won't disappoint them if your
project runs into speed bumps.

------
scotty79
They just didn't underpromise enough. They should have promise only what they
could deliver with half of the team working 3 days per week and overdeliver
things by making 3/4 of our team working 4 days per week.

They would have happy and amazed client and lot's of spare strength.

------
Flakes000
he is very right, you can't make yourself work so hard and show nothing for it
except everyone being too tired to continue working. And you giving someone a
false image about yourself can come back to bite you when they expect you to
always be like that and perform the way you showed them or better..

------
damontal
"Do I care how long it takes a mechanic to fix my car? No, I just care that
its fixed."

Really??

~~~
yen223
Yep. If - like most people - you know nothing about cars, then you wouldn't
know how long it actually takes to fix your car. So if the mechanic chooses to
'over-deliver' by fixing your car in 3 hours, instead of the actual 6 hours it
takes, that's going to set your expectations. You'd think that it takes 3
hours to fix a car, and you'll be pissed when the mechanic takes 6 hours the
second time around. Which was the problem the author faced.

~~~
unreal37
Mechanics don't even charge how long it actually takes. They charge a standard
(arguably, over-inflated) amount for a job regardless of the actual time.

So it does take 3 hours to fix your car, and they charge you for 6. Then you
care.

~~~
otoburb
I'm not a mechanic, and know little about cars. However, whenever I've taken
cars in for service I find that the shops charge me labour and parts, and they
are often clearly itemized on the invoice.

The reason that it seems they charge a 'standard' amount for a job is because
certain jobs (changing brakes/tires/oil, general checkups, car detailing,
etc.) have been enough times across the industry and in the shop that reliable
statistical (or consensus) baselines allow one to more easily and reliably
estimate.

Admittedly, this doesn't fix the original principal-agent problem[1], but I
thought I'd throw in my experience with mechanics and getting cars serviced.

[1]
[http://books.google.ca/books?id=4XcR7Y5ddcoC&pg=PA323&lpg=PA...](http://books.google.ca/books?id=4XcR7Y5ddcoC&pg=PA323&lpg=PA323&dq=principal-
agent+mechanic&source=bl&ots=FPut69nJL_&sig=madAnluCPf7YjdMeryDxiPfgHz0&hl=en&sa=X&ei=8EzJUbrlDsvnigKgkYGIAQ&redir_esc=y#v=onepage&q=principal-
agent%20mechanic&f=false)

~~~
rimantas
AFAIK, service stations even have catalogs (from manufacturers, no less) which
specify how much time specific repair will take. Clients are billed according
to that, and not the actual amount of time mechanic spent.

~~~
otoburb
I misinterpreted your statement. You are right -- if an unscrupulous mechanic
tried to charge you for more hours of labour than what the catalogs specify,
then we'd care and would probably pick up on it a lot faster.

------
nknighthb
Yeah, that's not how you do it.

1\. Under-promise for a sustainable output pace.

2\. If/when you finish early, everybody gets an appropriate amount of time
off.

3\. Repeat.

Your client is happy, and your team is happy, healthier, and ultimately more
productive.

