IT Consulting: A Comparison Between Two Different Worlds

Kaleigh Blessard
February 18, 2016
10:09 pm

IT Consulting:
A Comparison Between Two Different Worlds

In reading the title of this blog post, you are probably thinking to yourself, “what is that supposed to mean?” Let me try to address this up front. In this post, we will be discussing at a high level:

My impressions from previously working at a large, technology-agnostic IT consulting firm comprised of over 100,000 employees spanning a worldwide organization.
My impressions now working at TekStream Solutions, a small, boutique Oracle IT consulting firm comprised of around 100 employees located in the United States.
Comparison between a small subset of the challenges, and methodologies employed by both firms.
Conclusion from my experience that in some ways size does matter but in other important ways it does not.

When I worked at the large professional services firm, processes were regimented and templates were used wherever and whenever possible. This had both its advantages and its drawbacks. From a strategic view, it was less important that every client-specific business process or unique business rule was accommodated than it was that wherever possible, an SDLC implementation (using the same technology and fulfilling the same high level business requirements) from one client to the next utilized the same approach and methodology.

That is not to say there weren’t exceptions (consulting wouldn’t be consulting without those!) or that every client-specific business requirement was not captured or put in to a project change request. Instead, we had and were expected to use our leverage to preserve standardization. Specifically, we had the leverage to be able to tell and sell to the client that we have done X successfully Y number of times across Z clients – we strongly recommend that you utilize our approach. In general, this strategy worked well in that codebases could be deployed across clients with minimal customization. This came at the cost of the happiness of some business users who felt that their specific needs were not being addressed.

Additionally, there were several projects I worked on where re-work was needed because the functionality that was implemented did not work for some use cases because specific business requirements conflicted with what was done. The flip side is that the firm was able to dedicate entire project teams to one client and only one client, which helped to foresee and identify these situations earlier rather than later. In any case, this problem is one that tends to come up in a lot of projects, but I did see this come up more frequently when working at the larger firm. However, given the scale of the organization, this may have been seen as an acceptable and indeed necessary level of risk needed to be absorbed in order to operate efficiently at a large scale.

Working at TekStream Solutions gives me a different perspective on how to approach and tackle some of the same challenges and opportunities I encounter in working with my clients. On the one hand, I do not have dedicated support staff to handle administrative functions that project managers at a larger firm would have. On the other hand, precisely because the firm is so small I have direct access to executive level resources to whom I can quickly escalate issues. Again, this has both its advantages and its drawbacks and colors the interactions I have with clients differently. However, the end goal is the same – successfully deliver and deliver to the client’s satisfaction.

At TekStream Solutions, as a focused Oracle software consulting services provider, we have the advantage of working with clients who already have the expectation up front as to exactly what technology will be utilized on a given implementation. So although the TekStream Solutions requirements gathering phase (QuickStream) process is much shorter the process used at the larger firm, from the beginning in the high level requirements all the way downstream throughout the life cycle of the project, we are able to focus more on addressing client-specific customizations and business requirements. Given the access to executive-level escalation points I mentioned earlier, deviations from project scope tend to be more swiftly addressed and execution of project change request and client acceptance can occur in an order of days, not weeks.

This approach comes at the cost of sometimes spending more development cycles in burning effort to meet custom requirements than always is beneficial strictly from a margin perspective, but in my experience has come with the benefit of gaining a lot of client goodwill in our sensitivity to their specific needs and business use cases. Re-work tends to also be avoided when as many use cases as possible are addressed before development starts.

In conclusion, in working at a large IT consulting services firm and at TekStream Solutions, I have seen different tactics utilized to address different strategic objectives, but the end goal is the same. One can certainly make the case that, were TekStream Solutions as large as the consulting firm I had previously worked at, its methodologies would need to adapt in some fashion in order to successfully operate at the same scale. This point granted, generally both kinds of organizations leverage their competitive advantages with clients in order to accomplish the same objective – deliver on time, on budget, to the customer’s satisfaction.

My hope is that the reader can come away from this post with a couple of points that he or she may find useful to keep in mind when working through similar situations in his or her organization and gain insight as to what may be a viable way to handle a challenge by leveraging his or her organization’s strengths.