Learning to Fire Contractors

Quick Links

I have run into a few situations recently that made me think about when and why I would fire a contracting organization (assuming they did not resolve the issue immediately). Obviously there are exceptions, so use some common sense. But do not let an abusive relationship form where you will always come out as the loser.

Here are my tips:

If your contractor does not work in an online system where you can see all work artifacts at any time as they happen...

Fire them.

If your contractor is not transparent, showing you the good and bad that happens along the way of the project...

Fire them.

If your contractor does not engage you, the client, every day...

Fire them.

If your contractor decides on business logic without your input...

Fire them.

If your contractor does not produce demo-able work on a weekly basis...

Fire them.

If your contractor works without user stories, use cases, or some form of description for the work to be performed that both parties can understand...

Fire them.

If your contractor does not prove their architecture, scalability and performance to you early in the project...

Fire them.

If your contractor saves all the risky work to the end of the project...

Fire them.

If your contractor does not let you prioritize the work by business value...

Fire them.

If you do not trust or have confidence in your contractor after working together for 3 or more months...

Fire them.

If your contractor does not seem to care if you are happy with their work...

Fire them, unless you are happy with their work.

Now if you are in doubt, call me and I'll fire them for you.

Jayson Minard used to work here. At DevZone that is, but has been away and now snuck back to write this article while Cal was hung-over from ZendCon Happiness.

When he is not sneaking into DevZone, he strengthens his background in e-commerce, highly scalable applications, search systems, software development processes and commercial software development. He has developed far too many software systems ranging from desktop applications through extremely high volume distributed systems.

Jayson currently operates MindHeap Technology, providing technology strategy, architecture, product management and development consulting at high levels in client organizations; from architect through CIO/CTO. He works with clients such as Endeca, Boeing, ProQuest, Zend, AbeBooks, Alibris, JobMagnet and is also the CTO of TinyMassive. Previously, as CIO and CTO of AbeBooks, he rebuilt the IT organization and technology platform and brought AbeBooks to a level playing field with the likes of Amazon, Barnes and Noble, and Half.com. That success has led to a recent acquisition by Amazon.

Jayson works across PHP, Java, Ruby and .NET platforms balancing his time and experiences to stay strong in each. In fact in the PHP world he created the Zend DevZone community site and was the founding Editor-in-Chief, created the strategy for ZendCon, and led the Zend Framework open-source project. He contributed to the Java platform as the Chief Architect for the Java Business Unit at Borland creating JBuilder and shaping early Java specifications. Jayson also has experience with most major database platforms, enterprise technology and grid computing.

He has been in software development for over 20 years but still thinks he will some day be a movie producer or own a recording studio. Instead he owns WorkSpace Cafe in Vancouver which is a hang-out for people seeking a better place to work.

Comments

Thursday, October 2, 2008

MICROMANAGEMENT

9:25AM PDT · Pugi! [unregistered]

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.

MICROMANAGEMENT, OR TRANSPARENT DEVELOPMENT?

11:55AM PDT · Jayson Minard

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.

Monday, October 6, 2008

A BALANCE IS NEEDED

1:49AM PDT · ianb

"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.

Friday, October 24, 2008

WISH I'D READ THIS YEARS AGO

9:36AM PDT · symcbean

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

Tuesday, January 13, 2009

GOOD GRIEF

8:50AM PST · furq

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