I was heading to work for my new client this week when something fairly mundane happened to me. While entering the elevator, a woman bristled against me. After apologizing, some small talk ensued:
- Advertisement -
I was heading to work for my new client this week when something fairly mundane happened to me. While entering the elevator, a woman bristled against me. After apologizing, some small talk ensued:
Me: Don’t worry about it. I’m used to being hit. I’m a consultant.
Nice Lady: What type of consultant are you?
- Advertisement -
Me: Technology.
This innocuous exchange had me thinking all week.
Now, at 6 am, I’m hardly about to bore a nice lady with a long, detailed description of the nuances of what I do. This isn’t to say that what I–or many consultants–do is fundamentally or necessarily boring. It’s not. But it’s pretty presumptuous of me to assume that, from her query, she wanted anything more than a simple answer to a simple question. Plus, did I mention that it was 6 am?
This little exchange affected me all week. I kept wondering, “What type of consultant am I?”
Traditional Types of Consultants
When I started consulting in 2000 (arguably the height of Enterprise 1.0), I quickly became aware of three general types of consultants:
- Advertisement -
- functional consultants who knew how to configure applications
- technical consultants who worked with security, databases, servers, and other “behind the scenes” things
- strategic consultants who did, you know, “strategic” stuff
This is no accident. Historically, many large consulting firms or system integrators (SIs) have intentionally segmented consultants for several reasons. For one, to be fair, no one person (no matter how bright) can know everything about a large enterprise application such as Oracle or SAP and the business that it’s trying to serve. Second, it takes time and money to train consultants and SIs to place their consultants on projects to recoup their investments. A byproduct of this second reason is that many consultants have been typecast. SIs would send in specialists at occasionally exorbitant rates because no one consultant could do everything required by its client. Again, this wasn’t altogether false, but the benefit to the SI here should not be overlooked.
Enterprise 2.0 and the Blurring of Terms
So, with Enterprise 2.0, have traditional consultant classifications blurred? Are most consultants becoming equal parts techie, “tool jockey” and trusted business advisor?
Speaking for myself, I’m pretty much staying the course. On enterprise software consulting gigs, I have always tried to know as much as possible about applications, the technology and database tables behind them, and the business reasons for the project. I just didn’t like being pigeon-holed. This isn’t to say that I’m somehow more evolved than all or even most consultants. I’m really don’t think that I am exceptional. I know others who refuse to limit their knowledge to one narrow area. People like us are fundamentally curious and we like to solve problems.
But what about these large SIs? Let’s just say that I have my doubts. For years, I have not seen eye-to-eye with the practices of huge consulting firms for a whole slew of reasons, many of which are outlined in a recent lawsuit. When I read about lawsuits like these and hear stories of IT projects gone wild, I wonder if large SIs are still mired in old ways. Are they continuing to train specialists at a time of collaboration and the widespread dissemination of information? Do they hope that we somehow revert to the halcyon days of Enterprise 1.0?
Feedback
What do you think? What kind of consultant are you? Are strict classifications changing?