General Consultant Discussion

Is it just me or is project-creep a problem for more people? It starts with one innocent ""quick question"". From there it's a longer phone conference. Usually this barely involves you but the customer wants your opinion. Then finally you are pulled into the fray - meetings, conference calls, etc -- before you have a chance to even setup a project or price.

Wayne, we've structured our fixed-price projects with deliverables that have controlled this well for us. We do spend more time up front coming up with the contents of the 3 options, but when done, it's pretty clear what they are NOT getting. Especially with projects that we know will generate creep as the customer actually starts thinking about the details, we close those off in the SOW. Some things, like reports are always hard. So I use a design process instead. 1. the SOW describes the report, parameters and purpose. I structure that explicitly based on our talks, and purposely describe it to exclude the obvious ways it gets extended. (reports always start simpler than they end up). If I think they'll want to extend it, I'll explicitly describe that in a higher option. again, so they see that they are choosing. 2. they agree to the SOW, and we do a draft meeting those objectives and parameters. We deliver that, and go through details with customers. we will agree to changes within the limits of the original description, and of course the cosmetic and layout changes. 3. We do draft #2, and now the customer can make ONLY cosmetic changes within the limits of the layout approved after Draft 1. 4. we make the cosmetic changes, and we are done. For ""quick questions gone wild"" situation. The trick here is deal with the only quick question, and explicitly tell them that further consulting on the problem wasn't part of the SOW. It puts them on notice for when they come back. Better still, you usually see these situations coming when you layout the original work. Bake in further consultations as PART of the Premium option. When they want you to consult, you remind them that they passed on that option, and that the Premium option, +20% of the difference between the option they bought and the Premium, applies. (This is part of the T&C for each proposal.) Some of the ways we've learned to deal with related problems are in our customer agreement, which is in addition to the actual project plan.

@JerryNorman - nice job Jerry, thanks for sharing your agreement, very clear.

Actually my problem is much more basic. It's the ""hey I have a quick question"" which looks like a support question but 15 calls later.... you're helping them design and integration to a third party system. Mark calls this ""death by 1,000 papercuts

Carry a box of bandages and bill at rate X papercut?

The problem I have is recognizing a project vs a routine support request. i find that the issue is most prevalent when a customer is working on a project that they've started on their own -- integrations are probably the biggest cause of ""question becomes a project'.

This is a challenge, especially for folks who Kless calls ""solutionists"" because you get in this trap by only focusing on the solution to the immediate question coming from the other end of the phone. I don't handle this right 100% of the time, but it does really help to stop before answering the immediate question, and put on my sales hat. Start asking questions about the project they are doing, what its goals are, what triggered it, etc. Pretend I'm starting to discover the value of the project's result to the customer's management. After not too many questions, I will know what sort of category this is in, and I get a good sense of the questions and problems they will eventually run into. At this point, I can briefly point out where they are likely going, and offer to help them streamline it - for a fee. When/if they decline, I now can quite firmly point out in their next call that I'd offered to answer these questions earlier, but they declined.

Just let them know they are on the clock from the beginning and they will be more respectful of your time from the start and you will be paid from the start or it will weed out the ones not willing to pay for your value. Sorry I just had to say it. Start the hourly bashing.

Bob, the approach I outlined is actually easier all the way around. And unlike the time-based way you suggest, this actually does lead to more consulting.

@BobKohlmeyer I don't think that my team's value is based on how much money we charge by the hour but rather what we can accomplish for the client. You are right about making sure that they will be respectful though - that's why you start with a discovery project. Even for a nominal scope / fee, it will separate the serious from the not serious.

I find it is usually more complex than the relatively easy concept of hours vs fixed. The customer expects that what they're asking is a 2 second question. Much of it is covered (or at least I consider it covered) under support. The problem is when they unexpectedly come back 5 more times with quick questions. By the 6th you're actually in the middle of an unpaid project.