Client mis-managing my (contractor) work

Question

I'm a newly-minted (~1yr) contractor, providing specialist technical services (Machine Learning). I am on my second job; first one was great (more on that below) and in fact they referred me on to my new client. My current client is a technology start-up, with software developers but no-one else with my expertise. I am only 5 weeks in, but the new client is micro-managing the projects they set me despite a lack of understanding of the subject matter, steering the projects towards failure. I want to avoid this situation affecting my relationship with the first client, and ideally put my current job back on track. Any advice on how I could do it?

Normally, I would perhaps consider getting out of the project amicably and looking for something else, however the client is a company that has a relationship with my first client (they recommended me), and I am hoping for repeat custom from my first client.

How can I protect my relationship with the first client? I fear that if I push back or go away from the project, or alternatively continue as-is and not deliver as a result, that would adversely affect my reputation with the first client.

Besides, I'd rather do a good job with my current client, but my expectations here as low.

Examples of the difficulties I face:

• The top-level requirements, scope or objectives of multi-month projects are changed weekly
• My projects are micro-managed: the client insists that I work only on particular parts of the project (to first test viability). The results are good, but then the approach is canned because the client doesn't like the 'feel' of the approach (purely non-technical or non-business reasons), or it isn't a complete solution (as expressly desired by the client in the first place).
• I am lectured on fine details of stochastic gradient descent or random forests and how they cannot possibly perform better than something my contact (a historian) thought up on his way to work. I then end up spending time resolving such queries, instead of furthering the project.
• My work is discussed without me being present, and from what I gather, it is usually mis-represented, not out of malice, but out of lack of understanding. This affects the way the projects go, and ultimately my reputation as a problem-solver.
• My suggestions of how to make more progress with more structure are heard with kindness, but not put into action.

Perhaps fault lies with me? Maybe I should behave differently in this environment? I don't have much experience of being a contractor, suggestions very welcome!

Answer 1

You're working for a startup, probably delivering your work product to unseasoned engineers and managers. They micromanage you because they're anxious and inexperienced, and they think it's the best way to make their little company successful. (I know this: I have been that micromanager from a startup, and I have been micromanaged by startups.)

Their job is to get over their anxiety, stop thrashing around, and build some value. And, you're getting a brutal introduction to your job as a consultant to a startup: to teach them not only your specific trade, but how to make best use of consultants. You also have the job of educating your client (the historian) in the details of your trade.

Consultancy isn't just tech wizardry. It's helping your clients succeed at whatever they're trying to do.

Somebody at your first client referred you to these startup guys. May I suggest you contact that person and say something like, "Do you have a few minutes to talk? Do you have any suggestions about working effectively with this startup? From my perspective they're thrashing around a bit. Is there anything I can do to help them stay focused?"

(Don't disclose any trade secrets.)

This conversation will help you in several ways.

1. People LOVE being asked for advice. You will build your relationship with your first client just by asking the question. Most people are honored when you treat them as mentors.
2. The conversation will help you understand the startup situation. Hectic.
3. You may get some good advice about the personalities in the startup, and how to work with them.
4. You will be in control of the way the first client understands your consulting engagement with the startup.

This kind of thing, even though it's painful, is tremendously valuable experience for you.

Finally, keep in mind that it takes people time to accept advice. When you tell somebody, "you're wrong, here's why" they never smack their foreheads and say "doh! you're right, I'm wrong, we'll do it your way." Give them time. A few days later they will claim your idea as their own. For a consultant, that's the sweetest kind of victory.

Answer 2

Well, that is a difficult client to handle. Here are the minimum things you need to try.

1. Ask the customer for the most important requirements, in therms of QCT: the minimum mandatory description of the final product, the final deadline, the money they are willing to spend.

2. Ask them to prioritize the requirements with regards to QCT.

3. Assign time and cost estimates to requirements.

4. Maintainan project plan, show them how the deadline is jeopardized by each sudden request.

If they react to this, you are lucky. You can go on, and build healthier project management practices with them.

---

You might be lucky to have someone to aid you, e.g. a boss in your company. That might prove a huge deal.

---

Study the contract you have with the customer and see the extend of what you can do to save the project. In which situations you can actually say "NO". Also, the maximum damage you can get in case of failure (of any kind).

---

Ask to have other people to aid you. While somebody does the rapid prototyping and viability, while someone else follows the healthy project path, to ensure at least partial success.

---

Perhaps fault lies with me?

Definitely NOT. I do not imply that you are perfect and there is no room for improvement, but what you are asked for is a total nightmare.

Answer 3

This may not help you resolve your immediate problem with this client, but I feel like you're (indirectly) learning an important lesson:

In any job, but especially as a contractor, you need to be aware of what type of work you've been hired to do. Generally, that means strategic vs tactical, or leader vs. doer. If you're being hired as a doer - someone who does tasks - you need to be OK with the fact that you can't control the leadership of the project. You need to be willing to work under someone else's direction. You may be an expert, and you may legitimately know better, but someone else is paying you to do what they want you to do.

If that makes you unhappy, you need to focus on finding projects where you will be placed in the driver's seat. Some clients will realize that they're not knowledgeable enough to control a project, and will be happy to hire someone who can make decisions and do work. The limiting factor with this approach is that you'll generally be stuck with smaller, less important projects, simply because once an effort gets large enough, you need multiple people segregated into different roles.

Answer 4

It seems like your client sees the contract as an unstructured prototyping exercise rather than a conventional SDLC project. They seem to be learning as they go, but may not recognise this, and they see you as a mere facilitator rather than the SME.

You need to persuade them that you are an expert in the field and get them to treat you as such. They need to be made aware that you have breadth and depth of knowledge. This may be difficult given the third bullet point. If possible, write things up (e.g. "activity x failed because of y and z, this is a common problem in this area and is usually dealt with by using method q"). If it isn't written down you are relying on the vagaries of memory.

Judging from the first two bullet points, they don't have an experienced project manager so you need to assume the role. Let them know about the risks and issues associated with the technical approaches they take (e.g. "I've seen this before and it doesn't usually scale up"). Again, do this in writing, preferably a formal RAID report.

It be that you don't like such an unstructured approach, or that you aren't the sort of person who wants to make a big fuss. That's fine, but in that case, the contract probably isn't for you.