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.

Ten songs that remind me of the Enterprise Software World


A list of songs – all linked to Youtube – that makes me think of different aspects for life in Enterprise Software world, and its many characters.

The many players in Enterprise SW market in action

The  sales process – wooing the customer

Software vendors referring to analysts

Independents vs big time  firms

Customer reaction to high maintenance cost of enterprise software

EnSW Customer with buyer’s remorse

Exasperated consultants stuck in production support for foreseeable future, having to fight problems created by their predecessors

Roadwarrior consultant/analyst to the newbie

Thoughtprocess before taking SW consulting as a career

Project managers, Product managers and Sales people who think they know know better than developers, forcing down their wishes against developers’ protests

So You Badly Want To Do Self Service BI, eh?


Every one and his neighbor wants self service BI. What does it take to get it? Is it even reasonable to expect that significant parts of BI can be self service enabled?

 

For one, self service is loosely defined, at least in the BI world.

 

First – no enterprise BI tool is really designed with the user in mind from my limited experience. Invariably, they are designed with a developer in mind.  This needs to change before self service becomes realistic. All BI vendors claim they are about self service, but if you look at the tools – it is hard to imagine them being people centric in design.  If users need training to make this work – it generally won’t fly. Simple as that.

 

Next is the distinction of BI users as defined by software vendors to suit the products they have. It is chicken and egg – over time, one cannot figure out if different tools exist because different types of users/usage exists, OR different users/usage exist because BI tools are not consistent. Either way – any real self service is hard to pull off with such distinctions.

 

Ability to search is next. Organizations do not lack data – it is usually there somewhere. What is not possible is an easy way to find all of this data that might be sitting somewhere. So there needs to be a way to find this data in a form that can be used. What is possible today is to search for names of existing reports and column names. But since they are not usually well-defined – making sense of the search results is generally a complex task .

 

It appears to be obvious that a consistent data definition – or a common semantic layer in hip terms – is required to make this work. Tools can do this today to various degrees – but the process to get it done is nowhere near easy. Try asking 20 people in a big company to define “net profit”, and you will get an idea of what I am talking about.

 

Users won’t trust data they see unless it shows how current it is. Some of the users will also need to make sure they can see how the data flowed from its origin to the report they have in front of them, and what transformations happened en route. This is not a self service  BI challenge – this is true in any BI scenario, but just that in self service this will become an even bigger issue.

 

Finally there is the question of support. When things don’t work – there should be an easy way for users to get support – via technology or via a human support person. Without integrating support in some comprehensive fashion, it is hard to sustain self service BI.

 

If you still want Self service BI, let’s go make it work. I am always game ! What are a few challenges between friends 🙂