Learning to Fire Contractors

Do you know the words micromanagement and control-freak ? I would never want to work like that, not as a developer and not as a projectmanager.
If your contractor does not engage you, the client, every day… If your contractor does not produce demo-able work on a weekly basis… What ? I knew plenty of projects where it is not possible/feasible/interesting to produce demo-able work on weekly basis (database design, unit testing, business logic, …). You agree on a deadline for the end of the project and some dates for demos (user interface, demo site, demo administrator interface, … so you can check progress), when in doubt or in case of problems they should always immediately contact you, weakly status reports, if you are a skilled developer or have developers in a in-house team you can also ask for use cases, datamodel, review some code, …
I might agree with you if your contractors are still in high school, otherwise either you trust them or you don’t sign the contract.

Let me ask the following:

“Why would a consulting company not want me to see their progress, and get my feedback as soon as possible to avoid doing the wrong thing?”

Am I bothering them by seeing the work? Is that annoying? Is it not valuable to demo even technical topics like a database ERD diagram walk-through? Or an architecture walk-through? Does it hurt to demo to each other even if the customer is yawning? To show our cool unit test growth rate? Or that we have automated builds and tests running? That we have user stories or use cases for the business logic to talk about? Those are all “demo-able work.” Demo equals demonstrable and the method of demonstration can be anything.

If you dig into my list you will notice it is mostly describing the tenants of Agile Development in reverse. Since when is Agile Development “Micro Management?” It is instead a process to provide transparency to everyone involved in the project and to keep everyone’s head in the game. It is also a realistic model that understands that surprises happen, things go awry and that planning most be ongoing. It “all comes down to communication” (credited to Rein Henricks) and many development groups are not so good at that “communication” thing nor can they really predict what information everyone wants, nor be responsible to alert each interested party perfectly. Bring everyone in, show everything, and let people filter for themselves.

Most of my topics aren’t about trust. It is about ensuring that you are getting what you want and controlling expense and risk. And even a good team can have a bad project so you should want to help prevent it from going bad. And they should want that help. I would think.

"Am I bothering them by seeing the work? Is that annoying? Is it not valuable to demo even technical topics like a database ERD diagram walk-through? Or an architecture walk-through? Does it hurt to demo to each other even if the customer is yawning?"

Genuinely I think yes, especially if the client is smaller or you’re dealing with someone that is very busy, why should they sit through an ERD walk through? You’re the technical contractor, you’re the one they’ve hired to provide that aspect.

I think that there are situations where there are technical people on both sides of the fence, and giving them every last details is valuable, but there are a great many situations when you are just taking up your own and the clients time and costing them money for very little return.

Communication is important, but it’s just as easy to overburden the client with information, and push decisions that you need to make back to them too much.

It might be a tad over-zealous, and even obvious, but I now know from experience where you’re coming from.

Reading this it made me wonder more how I would fire a project manager, good grief.

Thanks for the article. I hate having to fire people. I usually put it off for a while. Till i work up the courage.

Thanks for the post. Fire the contractor. Poor bugger. Should have done a better job

Some of these guidelines are pretty harsh. I think it always comes down to a case-by-case basis. Not so much generalized guidelines but more like "what feels right" and "what gets the job done". Remember that we all can have bad days and deserve 2nd chances.

Woow, pretty harsh. Might work maybe in an ideal world, but not in this one. What about project timelines? Delays? Additional work to find a replacement contractor? All these issues will be taken into account before anybody decides to let go their partners.

My advice it to work on the communication and clearly message that unless there’ll be changes made, we are not going to continue. If nothing happens, then fire them!

And get a different contractor in the process, so the change is as painless as possible.

The harshness may have been used to push the point and give a wakeup call to those who let their projects go down the drain due to chronic bad behaviour by a service provider. I’m referring to those providers that make the above behaviour their way of life. And believe me, there are plenty that do.

Of course you have to balance all factors and mitigate the impact on the project. But you also have to learn when to cut it off and move on to other answers. Plenty of projects have failed due to a lack of a well time "project reset" while others have failed by doing too many resets.

Use the above firing guide as a list of "contracting smells" and if your project starts to stink, look deeper to find out what is really going on behind the scenes…