The Tariq Effect

Sat, Aug 27, 2011

Picture the scenario: You’re working on a high profile account work millions of Pounds in charge of a team of skilled developers all working to create the client’s next generation system. You have to interface with different teams throughout the project as is the nature with any large delivery project. Teams such as Business Analyst team, Rules team, Business Process Management team and a CRM team. All teams are working harmoniously with each other. Sure they have issues and blockers and sometimes your code needs a rethink but nothing out of the ordinary considering the project is of a fair size.

One major blocker holds your project back though. The Tariq Effect.

The Tariq Effect is a term I am going to coin to represent the negative influence on a project. There’s always one and usually it is someone who has another motive. I’ll aim to list how you can take control back over your project once the Tariq Effect has kicked in.

Disclaimer: I’ve worked with many fantastic contractors over the years in the I.T. industry, truly brilliant people. There are however ones that are better at cheating through life than actually working for it. It is those who I refer to by the Tariq Effect. This also applies to full time employees too.

1. Don’t let a contractor with his own contracting company be in a position of responsibility to estimate for work and hire resources. There is a massive conflict of interest here. For example when asked to estimate on a piece of work an estimate may be “we need 10 people to complete this work”. If he then turns around and says “actually I have 10 people working for my consulting company” then this should serve as red light. If you find yourself in this position take one or both of the following actions: double check his estimates using an independant resource - preferably someone not on the account. Remove him from the hiring process - again get someone else to do the hiring. That way there is no conflict of interest.
2. If you must have a contractor as a team lead do not let him get into the position where he is attending all the design meetings and thus is collecting all the low level knowledge on the account. He does this to specifically put himself in a position whereby you can not terminate his contract without also losing his knowledge. If this must be the case then the key is to force him to document everything. Meetings, chats, design decisions, etc. This should happen with any consultant, not just contracting consultants. It is a clear sign that someone is manoeuvring themselves into a position of power if you see that happing.
3. Don’t accept delays / sloppy work without good evidence. A common ploy with the Tariq Effect is to claim that it is “impossible” or that “the system will break”. Using such language fills project management with fear so they don’t question why basic coding standards haven’t been followed. If he can’t explain to you why it is impossible or show you the system breaking then assume he is playing you here. The key to the Tariq Effect is to prolong the delivery. Prolonging the delivery is bad for the project but extremely good for the contractor who is getting paid by the day.
4. Do not reward employees for failure. This point is crucial. As an employee you must be responsible and accountable. What does accountability mean if you do not back this up at a project level with recriminations for sloppy work? Another characteristic of the Tariq Effect is that you find yourself making excuses for bad work on behalf of other people.
5. If you hear or see the contractor blame someone else for a piece of work when the other person isn’t around to defend themselves then stop them mid sentence. The idea here is that the Tariq Effect will blame another developer entirely for his mistakes. A project manager doesn’t know the truth (unless he / she is micro managing everything) so errors on the side of caution and sides with the person who is present and talking. Again, this is merely to extend his / her time on the project since that ultimately means more money regardless of sloppy work.
6. Set these people realistic dates and do not accept any slippages. The biggest trick in the Tariq Effect is befriending people on the project. For example I ask when a piece of work will be finished and receive the reply, “I was busy with other things this week, it’ll be done next week”. The following week I receive the same response. Befriending people on the project has meant that I accept the first excuse and am more inclined to let the second excuse slide as well. Ultimately, work has been delayed for no good reason. If this happens you should be fearless enough to report them to project management. That’s what the PMs are there for.
7. If developers on the team troubled with the Tariq Effect complain that they have not been given clear instruction it is simply because the Tariq Effect wants to keep the knowledge to himself. This isn’t good for the team and it certainly isn’t good for the project. As a PM take the time to speak to the individual team members if you suspect something is not quite right.
8. Lastly, a clear sign of the Tariq Effect is when no care is taken in basic developmental practices. Incorrect or sloppy use of the defect management tools, no source control management, not documenting, no unit testing, not designing up front. These are all ways with which to create confusion and noise so that their contract lengths are increased.

There is one simple thing that a project manager can do to alleviate this. When you see the Tariq Effect start to take hold - fire him. Give a three strikes and out warning and if not satisfactory after that then fire him. Managing someone like that and the fall out from the shit storm they create is a full time job in itself. Your project will be better for it.