The curious case of Junior Consultants

Off late in the blogosphere, there is a lot of chatter about why no customers want to pay for junior consultants in projects. I could not make my point in 140 characters – so I am trying the long form here, for whatever it is worth. And as always this is strictly just my view – not my employer’s view on the subject.

So who is the junior consultant? At SAPPHIRENOW 2011, I met a guy who is the manager of the best New GL migration expert I know of in SAP space. And the manager dude said something like “If you are impressed with that guy, you wouldn’t have any words to describe how awesome I am in new GL. That guy is good, but he is pretty junior compared to me”. Very cocky – but, he proved a point that “junior” is a relative term.  For the record – in this case, the Junior guy in this story would be more senior than most people you would find in SAP projects.

So what is the problem with junior consultants?  The prevailing thought seems to be that consulting companies staff junior guys in a project and charge exorbitant rates. There is probably some truth in that – no smoke without fire. However, there are perfectly good reasons to have junior consultants in a team.

1. Every one needs to start somewhere. The senior consultants of today were all junior when they started. And considering the fact that rates where much higher in late nineties than today, it is not fair now for the current seniors to say the juniors are not worth it. And on a slightly tangential note – the level of seniority needed for a project is also often exaggerated. I don’t know how many times last year I got unsolicited job emails that said someone was looking for 5 plus years of CRM 7.0 experience. How on earth can you have that when the product has not been around for 5 years?

2.  Know the type of contract before you make a big deal out of this. In a Time and Materials contract, the customer carries the risk. Customer needs people with the right experience, and there is no excuse for a consulting company to send some one with less experience without disclosing it upfront. However, not all contracts are time and materials based. Several are fixed price based. In Fixed price – typically, the consulting company takes the most risk. They are held to an outcome, and it should not matter if that company does the job with 2 senior consultants or 1 senior consultant and 2 junior consultants.  What I have seen is that irrespective of type of contract – the expectation is always that consultants have to abide by the Time and Materials mode. Again – there is no excuse for trying to do a project with only junior consultants without experienced folks to oversee their work.

3. Not every task in a project needs the most experienced consultant. If I were to ever work in the role of a client – I will never ask for a senior consultant to type up documentation, do routine configuration or development, or do routine testing. Experienced consultant’s value is in creating a great design, and then helping the team trouble shoot problems. If you make the senior person do everything – this consultant will probably be dead bored with what he/she does and do a sub par job, plus it will become prohibitively expensive for project to pay higher rates for low skill tasks.  Where as, junior consultants will be perfect for the routine stuff. They will be less expensive – and will have the drive to do all the stuff that appears boring to the senior person, since it is not routine to them. To the junior consultant – it becomes a great learning opportunity.  In the quest to do one-size-fits-all, some people make this mistake of saying they only want senior consultants on the project.

4. Finally- junior consultants bring fresh perspectives to projects. They usually know things no one else in the team knows, and I know first hand the opportunity cost of not using their ideas in projects just because they are junior.  Junior consultants are not dumb – they are incredibly smart, if only their managers and seniors in the team take the time to nurture them and give them a fair chance to express their opinions. I have been guilty of this in past myself, and I have suffered this from my prior teams when I was the junior guy. So this is very close to my heart now.

5. Actually, there is one more reason juniors should be preferred in some long term projects. You need continuity in domain and industry  knowledge to be retained in the team, although the type of expert level technical skills might change in future phases of project. It is much more practical ( less cost, less chance to leave because  of boredom and so on)   to let a junior grow into this role than keep a senior tied to it long term.

So, while there is absolutely no excuse for a junior consultant to be presented as senior – there are good reasons to have them in your project teams, and I will strongly argue that they add significant value to the projects.