Autopsy Lesson #1: Don't Serve Nasty Left-Overs(marcusblankenship.com)
marcusblankenship.com
Autopsy Lesson #1: Don't Serve Nasty Left-Overs
http://marcusblankenship.com/home/2014/1/19/lesson-1-dont-serve-left-overs
5 comments
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.
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.
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.
Thanks, Patrick. Great advice! You captured the essence of the deal perfectly, with all its subtleties. (the "dribs and drabs", etc.)
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.
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.
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. ;-)
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. ;-)
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.
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. ;-)
Who else read the title of this post and expected something vastly different?
Hmm... what did you expect?
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.)