

Autopsy Lesson #1: Don't Serve Nasty Left-Overs - marcuscreo
http://marcusblankenship.com/home/2014/1/19/lesson-1-dont-serve-left-overs

======
patio11
There exist a variety of ways to handle this. Declining maintenance work is a
strategy. If that works for you and your clients, bully for you. Maintenance
work sold properly can both have fat margins and be a powerful sales tool,
though, so many consultancies offer it.

I think you're correct that slicing off 30 minutes here and 2 hours there is
nearly useless for clients because of the switching costs involved in
intellectual work. You need to reach flow state to do well by them. So don't
sell them anything which structurally inhibits flow state.

Let's say, for the sake of argument, that we're mutually skilled, that our
core offering is charged by the hour ( _cough_ though it would be better for
everyone if you switched to daily or weekly rates _cough_ ), and that the core
offering costs $200 an hour.

Here's the maintenance contract you sold: "We'll do maintenance work on an as-
available basis, up to your budget of 20 hours a month. I'm not going to carve
out preferential scheduling for it, though, so it will be dribs and drabs when
the team has downtime. Maintenance work costs $200 an hour times the number of
hours consumed."

Here's the maintenance contract I'd sell: "Thanks for investing $200,000 in
getting your project completed with us. You and I both know that, after we
deploy this project, you're going to discover through your customers' use of
it that we didn't anticipate 100% of the stuff you'll want. That's totally
natural in software. Tell you what: we'll sell you a maintenance contract on
the project for $5,000 a month. We agree to maintain internal expertise about
your project and the staffing flexibility to promise you development services
in a timely fashion responding to any fixes or feature requests you have, up
to 2 days worth per month. If you need more than that, or if you do not buy
the maintenance contract but need help anyhow, we're more than willing to
listen to a proposal for a new MSA and SOW, subject to our then-prevailing
rates and availability."

After I've sold four clients on maintenance contracts, one of my developers is
essentially full-time paid for by maintenance, so I will always schedule
engagements with one developer hidden behind my back. (One dev means one full-
time equivalent, not necessarily "Hey Bob, you're our maintenance engineer,
who suffers so all the rest of us can do the fun, intellectually engaging
work.") They're paid for but, crucially, not 100% utilized, which allows me to
have a slack-time reserve for e.g. unplanned employee absences, internal
projects, or one-off sprints for maintenance customers which are technically
in excess of what we've sold them but justified by our desire to delight long-
term good customers who probably haven't been diligent about using their
entire allotment every month. (Note for people who haven't run consultancies:
What does a $5,000 a month maintenance contract cost if you don't require any
work in a given month? $5,000. It's like health insurance: just because you
don't have your appendix burst doesn't mean we give you a rebate.)

~~~
phpnode
one issue I've found with this approach is that clients are now incentivized
to use those hours each month regardless of whether they really need them.
Inevitably this results in a whole host of disparate small tweaks and changes,
which are a pain to deal with.

~~~
patio11
It is possible that, if you sell something to someone, they will ask to take
delivery of it.

Giving them days of availability rather than hours minimizes the disruption.
It also gives you a built-in mechanism for teaching your clients to batch
their requests for optimal service.

------
thaumaturgy
This seems to be a pretty common problem -- I've inherited a couple of
projects suffering from this, and I've been guilty of it plenty too.

When a project goes to maintenance, it really becomes a completely different
project. The skills that launched the project aren't the skills that are
needed to keep it alive forever.

There are people who really prefer doing maintenance. They hate looking at a
blank page, but they're happy to chew through bug reports and feature requests
and make small changes to code or design all day long. Try to hire one or two
of those people (and, honestly, they rarely command the kind of pay rate that
a creative team does).

Client's happy, team's happy, you get residual income.

...I might be talking out of my ass though, I haven't gotten to this step yet.

~~~
marcuscreo
Hmm, interesting point that there are people who prefer doing maintenance. I
know of some large companies (PivotalLabs, Carbon Five) who avoid this problem
by not doing maintenance, but there probably is a nice market niche for teams
who love to do it.

I didn't know I was at that step until I'd had clients in "Phase 4" for a year
or more, and one of them said, "I feel like I'm getting your left over hours".
At that point I admitted she was, and suggested that I help find her another
team to work with.

I think Patrick's advice is key here: plan for how you're going to handle it.
You may not be at that step yet, but you will, I promise. Intentionally
planning to handle it will prevent serving left-overs. ;-)

------
didgeoridoo
We're a 28-person consultancy, and run into this a lot. One approach that
we've found to work is to help the client bring on at least one in-house
employee (contract or full-time) with enough technical expertise to conduct
updates and improvements. We then shift into a "leadership" role, maintaining
overall responsibility for the product's continued success, but guiding most
of the low-leverage day-to-day work to their in-house guys. Management, by
necessity, is much more amenable to "task-switching" than is hands-on
technical work, and represents a harder-to-find skillset for many clients, so
it's typically not too difficult to sell this kind of continued engagement.

~~~
marcuscreo
That sounds really smart. Even as an 11 person agency, we took on work which
required 90% of our folks to participate, because we always wanted to do
bigger things. Didn't really work out, as I may have mentioned. ;-)

------
paul_f
Who else read the title of this post and expected something vastly different?

~~~
marcuscreo
Hmm... what did you expect?

------
eps
His Creo is some other Creo, not the Kodak's daughter company.

~~~
marcuscreo
Ah, true!

