Jun
5
Know When to Walk Away
June 5, 2006 |
One of the hardest things for many consultants to figure out is when they should not be consulting.
The temptation is obvious and real. I mean, hours spent with a client are hours that you can bill. If an opportunity for additional work comes up, it’s very tempting to take advantage of it and rack up a few more hours and a bit more money, or to try and keep a project going in order to take advantage of it. I’m not talking about doing anything unethical, understand. I’m just talking about the normal inclination of consultants to try and get more work from their existing clients before seeking out new ones.
The motivation is obvious: it’s usually much easier to get work from an existing client than it is to get work from a new one. Sooner or later, though, it’s a tactic that will inevitably backfire on the consultant.
The reason should be obvious if you think about it: eventually one of two things will happen:
- The client will start to worry that you are, in fact, more interested in drumming up new business than in solving their problems, or
- A project will go bad.
Both of these are bad things for a consultant. And both of them have a similar solution; don’t be around all of the time. Your client doesn’t want to be sold things; he or she wants to be given solutions to problems. Pushing for work is a good way to be seen as someone who’s creating problems, or milking the person for money. I’ve always found that the best sales pitches start by showing that you understand what your customer needs, not by trying to convince them to buy what you have.
Also remember, you are being paid to solve problems. In IT, especially, that means that sooner or later the problem is supposed to go away. If you’re always there and there’s always new work to be done, even if it’s all useful and valuable, eventually somebody is going to start complaining that the problem still isn’t solved.
Is this always true? A lot of what I’ve said here is particular to the kind of consulting engagements I’ve worked on–in other words, IT or management consulting projects. The other model for consulting engagements might be called the “advisor” model, where you remain on call to your clients to be brought in for short engagements that require a specialized expertise. It’s certainly a viable model for doing business–but note that such consultants don’t hang around their clients’ offices hoping for work.
In short, you you need your client more than your client needs you, you’re likely to be looking for a new client soon enough.
Comments
What I'm Reading- Agile Requirements Information Model (4) – Subset For Agile Programs (a): Features and Feature BacklogScaling Software Agility
- The Great Implication of Context-Driven MethodologyJames Bach's Blog
- User stories versus Use CasesBusiness Analyst Blog
- Can Use Cases Possibly be Agile?Agile Product Owner (.com)
- A little bit of levity for the holidays from iRiseThe iRise Blog
- The end of reposiphilia?The Forrester Blog For Technology Product Management & Marketing Professionals
- IT ethics and the recessionIT Project Failures
- Risk Assessment ModelingEDS' Next Big Thing Blog: Read and Respond to What the EDS Fellows Say About Technology
- Test Requirements, Don't Test CodeHerding Cats
- Enterprise architecture is optionalBizRules Blog