Showing posts with label classic consulting. Show all posts
Showing posts with label classic consulting. Show all posts

Tuesday, 22 May 2012

Modern Consulting vs. Classic Consulting: Part 5 (Summary and Conclusion)

Ok, folks, we're down to the summary and conclusion of my series comparing classic consulting and modern consulting by way of our little thought experiment.

In this post, I'll be summarizing what we spent the last three posts examining and bringing things back full circle to the post that started this series (it's kind of like a flashback episode but without the laugh track).

No need for this today!

Let's start off with a little section I like to call...

Recap
Way back in the original post of this series, I'd stated that the company for which I work, BHS Consultants, is an "IT/technology consulting firm"; I'd also stated that this label is a "challenging" one.

By way of comparing and contrasting what I refer to as classic consulting and modern consulting, I set out to define what I meant by the two respective terms with the goal of showing why the label above is a challenging one for my company (which I will finalize in this post).

We compared the two terms by way of a thought experiment, defined as follows:
  1. You are in charge of a large project to implement a new business process that is to be heavily automated.
  2. You have a fixed budget and deadline.
  3. You currently do not have the expertise or staff to undertake and complete the project.
  4. You want to make as big (read: positive) an impression as possible.
We then considered three different options to tackle this project which can be summarized as follows:
  1. Find and take on an internal staff (either full-time or contract) including both SMEs (Subject Matter Experts) and implementors.
  2. Find and contract a knowledgeable consultant to advise on the project and then either field a staff to implement or contract out the work to another firm.
  3. Find and contract a knowledgeable "one-stop shop" that has both the SMEs needed and the manpower to carry out the plan/advice from the SME(s).
Each option is linked below for convenience (I know, I know; I'm just that nice).




Bringing Things Back Full Circle
So now we've seen three different options to address the same situation, all of which have their places.

However, in my experience, when it comes to consulting on technical matters (e.g. as in our thought experiment involving heavy automation)--especially where software and programming is involved--the third option is the one that makes the most sense, both from a time and cost perspective.

Some of you may argue that the above model failed horribly with the outsourcing fiascoes of the 2000s (I'm sure some of you had good experiences, but from my own experience and others I've dealt with, many did not), and that's a topic for another post.  It's difficult to argue with numbers that help your bottom line tremendously ($5/hour for 10 developers? that's tough to beat); however, you get what you pay for, and in many cases, it was either nothing or a product/service of inferior quality.

(Again, I'm not here to bash on every outsourcing venture, but am merely drawing from my own experiences and knowledge.)

But I've also witnessed (and been a part of) many successes with that same model with firms in North America/Europe (some would call it near-sourcing).  When companies see the value we bring with the deliverables we produce, it sinks in with them, and they become hungry for more, which we're only too happy to provide.

So What about That "Challenging Label"?
So why is being called an "IT/technology consulting firm" a challenging label for us?

Because, many times, it sounds like the company is a part of option number two, i.e. in the classic consulting space.  By that definition, BHS Consultants is definitely not a "consulting" firm; however, if you consider option number three, i.e. the modern consulting space, we most certainly do fit the bill.

Explaining those differences and trying to describe the services we can provide is perhaps the most challenging issue we face.  We certainly can't be overly esoteric about what we do, but to list the myriad skills and services we bring to the table would be an invitation to read through a novel!

Can you imagine this as a website?  Yeah, me neither.

Regardless of the challenges, though, we seek to add as much value to our clients as humanly possible.  BHS is extremely passionate about what they do, and I'm no exception. I wouldn't have spent the past decade plus here if I didn't absolutely love what I do.

And while "value" is usually in the form of deliverables (be they tangible or not), we always seek to help educate our clients (and even prospective clients) on the services we provide and the matters in to which they are delving.

Empowering clients to make smart, informed decisions about technology is at the heart of BHS Consulants, and should be at the heart of any IT/technology consulting firm; but being able to help clients actually realize those decisions is where the real value comes in to play.

Conclusion
Ok, there you have it!  We are finally through the entirety of this series!

Thank you for making it this far and reading through (hopefully) all of this series.  I do hope it's been insightful with respect to what I/we do, and with respect to the state of modern consulting.

Please do check us out at bhs-consultants.com (shameless plug, but hey, it's relevant!).

Remember: Both classic consulting and modern consulting have their roles to play in the right situation; but with the ever-expanding role technology plays in day-to-day operations of businesses and the ever-increasing request for plans and advice to be executed and realized, modern consulting will continue to become more and more relevant (and prevalent) by the day.

Thanks once more for your time and patience!

I'll see you on the next post!

Friday, 18 May 2012

Modern Consulting vs. Classic Consulting: Part 4

No funny sub-title today; no, sir, it's right down to business!

Recap
The situation we're considering is as follows:
  1. You are in charge of a large project to implement a new business process that is to be heavily automated.
  2. You have a fixed budget and deadline.
  3. You currently do not have the expertise or staff to undertake and complete the project.
  4. You want to make as big (read: positive) an impression as possible.
We are in the middle of examining three different options in order to accomplish this project, as described in the original post in this series.

Again, this series is not meant to be exhaustive by any means; rather, it is an analysis by way of my experience in the consulting business for the past 11+ years.

Last time we looked at option 2 (i.e. what I consider to be a description of a classic consulting scenario).

Option 3 is on deck for this post, so let's get cracking!

Option 3

Find and contract a knowledgeable "one-stop shop" that has both the SMEs needed and the manpower to carry out the plan/advice from the SME(s).

Now we get to the option that combines the role of the consultant and the role of the development team.  What I mean is that instead of sourcing the consultant from one firm and the development from another (or, if you're going internal for development, the development from there), you source all those tasks from a single vendor.


One arrow means one source of responsibility.

We can see in this situation that you only need to deal with one vendor.  Once the vendor is found and contracted, no more time needs to be spent in finding the appropriate staff/contractors to implement your plan once you have it.

What's more, the vendor has a vested interest in coming up with a viable plan that not only can but must be executed, as the same vendor will be providing the development resources.  What good is the plan if the vendor's own resources can't implement it?  Dragging out projects for the sake of additional billing is a serious red flag for any consulting firm.

The vendor is also more likely to be more flexible and accommodating for scope changes (let's face it: they do happen) than having a separate vendor for each purpose (as in option 2).

Project Management and Documentation

(This is a slight aside, but one worth mentioning.)

Often times, the vendor will assign a Project Manager or account liaison to work with you to complete your project.

If there's one piece of advice I can give with respect to having a PM, it's that they are worth paying for.

It's a common occurrence for clients to want to save money by reducing the number of line items and resources as much as possible.  Project management and project documentation are often the first things to go.  Do not give in to this temptation.  A vendor worth its salt will happily walk you through the benefits of having a project manager (as well as having proper documentation, both technical and otherwise).

Vendor Confidence
One argument that is sometimes made is that the client does not want to put all his/her eggs into one basket, so to speak.

I can understand some of the concern in this ("What if the company goes under?" "Will they be transparent enough in their internal interactions?" Etc.).  However, in my professional opinion, in the vast majority of cases, the benefits far outweigh the concerns.

A good way for you to vet the vendor is to investigate any references/testimonials they have (if none are readily available via their website or other means, don't be afraid to ask the vendor for some).  Due diligence is something you should always engage in, regardless.

As a slight aside, look for an honest vendor, and by that I mean one that won't say "yes" to absolutely everything (irrespective of data) and one that won't try to say "it can't be done" whenever you suggest a certain approach.  Consulting is largely about developing a relationship with the client and sharing in the risks and success of the project.

No, not THESE Yes men.

(Again, any such vendor worth its salt will anticipate these concerns and address each one with you.  Your peace of mind should be on the top of their priority list when it comes to dealing with you.)

Rates
It's also possible that the vendor will give a bit of a break on the rate given that you're engaging them not just for consulting/planning work, but for development work, as well.  More hours usually means a greater incentive to keep you, the client, happy.

You might pay a bit more for the lead consultant, but it likely won't be as much as it would have been from a classic consulting firm, and the development resources' rates will likely be less than the lead consultant's.

Also remember that you get what you pay for: Be way of firms that offer development work for $20/hour.  I've never been one for outsourcing, so please don't tell me about sending out your work for $1/hour for a team of 10 developers (I know the likely outcome of those stories).

Who Does the Work?
In most situations, the person performing the consulting should not be the only one doing the development work (this has been known to happen in smaller firms, but outside of smaller projects, this usually doesn't work out so well).  In fact, the consultant should likely not be performing any development in order to remain objective, available, and to "see the forest for the trees".

Pros and Cons
So let's list the pros and cons for option 3:

Pros
  1. Time spent acting as an intermediary between the consultant and the dev team is minimized.  Your time (and your team's time) is important.
  2. Time is saved not needing to find/contract both a consultant and a separate development team.
  3. Greater/enhanced communication between the consultant and the dev team, thereby bypassing/reducing potential miscommunication.
  4. Increased likelihood of successful plan implementation.
  5. Greater flexibility during both planning and execution phases.
  6. Reduced chance of budget and time overrun.
  7. The chance of getting a break on rate is higher (though not guaranteed).
  8. Greater perceived value, in addition to greater actual value (i.e. you're not just getting a document that "passes the weight test".)
Cons
  1. Potential "eggs in one basket" situation.
  2. Can be challenging to find a vendor that has both the domain expertise and development expertise together in one shop if you don't know where to look.
  3. May sacrifice laser-like competency and depth in a particular field for something more akin to a carbide drill or even an entire workshop (think about it).
  4. Increased need for vendor transparency (but this is easily addressed).
Unlike the previous two options, the pros far outnumber the cons.  

This option holds many advantages that address the concerns raised with option 2.

Synopsis
We see here an outline of what I refer to as a modern consulting situation; in other words, the vendor/consulting firm provides a "one-stop shop" for all of your project's needs.  This greatly simplifies matters and streamlines them, especially when you have a technical need such as the one described in this thought experiment.

The value here should be obvious, and while it's not always the right tool for the job, in most technical situations, it is (even in non-technical matters, having the consultant get their hands dirty with plan implementation can be beneficial in a lot of situations).

Yes, consulting is a "noble profession" (as Dr. Weiss puts it), but I believe that the definition of what consultants need to do--especially with respect to the ever-growing need for technical expertise--needs to evolve beyond just writing a plan.

I've come across more than a few consulting firms who do nothing more than produce reams of documentation for a plan that spans hundreds of pages, only to never see the light of day again.  To me, that's not only not adding any value, it's costing a business money and can even become a liability, and that's never acceptable.

Next Time...
...we'll wrap things up with a conclusion to this whole thought experiment and bring it back full circle to where the first post started.

(From Disney's The Lion King)
It's kind of like the circle of life that way <cue Elton John music>.

See you on the next post!

Thursday, 17 May 2012

Modern Consulting vs. Classic Consulting: Part 3 (or, The One with the Unexciting Title)

Welcome to part three of my continuing series comparing classic consulting with modern consulting!

We continue the thought exercise introduced in previous posts to investigate the differences between classic and modern consulting.

In this post, we'll be looking at a different option than the one we looked at in the last post in order to address the given situation.

What is that situation, you ask?  That's a great segue for the...


Wrong Segway(tm)!

Recap
The situation we're considering is as follows:
  1. You are in charge of a large project to implement a new business process that is to be heavily automated.
  2. You have a fixed budget and deadline.
  3. You currently do not have the expertise or staff to undertake and complete the project.
  4. You want to make as big (read: positive) an impression as possible.
We are in the middle of examining three different options in order to accomplish this project, as described in the original post in this series.

Again, this series is not meant to be exhaustive by any means; rather, it is an analysis by way of my experience in the consulting business for the past 11+ years.

Last time we looked at option 1 (i.e. doing everything internally).

Today we're going to look at option 2!

Option 2

Find and contract a knowledgeable consultant to advise on the project and then either field a staff to implement or contract out the work to another firm.

This is a typical fit for the classic consultant.  They're likely going to charge a sizable sum, but depending on what they actually deliver (or, sometimes, don't deliver), it can be worth it.  The peace of mind that comes with a well thought out plan that you can implement can be invaluable, but actually having a roadmap or plan that can be followed and you can rely on is where the real value is added.

Provided the consultant is genuinely interested in providing value (a trait Peter Block refers to as "being authentic"), you can hit the ground running with the project, save time in getting started, save money from not sinking money and carrying costs into hiring as many people as you would otherwise need, and be assured you have a solid approach.

Of course this all presupposes that you end up accepting and taking the consultant's advice.  Most times, however, barring some other pressures/circumstances, you likely will.

However.

Now you are left with the task of actually putting the consultant's plan/advice in motion.
  1. Do you go a similar route as option 1 and field the staff necessary to implement the plan?
  2. Do you contract out the work to another firm that specializes in development?
We've already examined the first possibility as part of option 1, so we're well aware of the costs in terms of time and money (and other considerations) that would need to be looked at in order to carry out this plan.

So let's look at the second possibility.
  • You will need lead time to find a vendor that best suits your needs (unless, of course, you have a vendor of record for such tasks).  This is likely to be shorter than the time needed to screen for internal staff.
  • Time will have to be spent so the vendor can gather requirements and you can share the plan you're working to implement.  This will likely take about the same amount of time as if you were working with your own internal staff (and provided that they are also utilizing best practices and processes, which they should be; if the vendor isn't, then that's a serious red flag).
  • You may well save time in development if the vendor is quite experienced as you can be assured their project staff and developers are proven and seasoned.  An internal staff might take longer to suss out in terms of these same qualities.
  • There is a single "throat to choke" and, God forbid, if things really go pear shaped, you can likely recuperate some of the cost (remember your goals from the first post in this series?).  We all know bosses who are impressed by the timeless art of "grinding".
  • The hourly cost of such a vendor are most likely going to be higher than that of an internal staff, but keep in mind you're no longer carrying much of the overhead, and you can engage them for a fixed length of time.
There look to be some real benefits in pursuing this model!

(Courtesy of: general-data.com)
Hopefully it's just a figurative approach.

But what happens if the plan hits a hiccup or isn't as rock-solid as we had initially thought and signed off on?

What happens if there are questions about the plan?  Is there a support contract in place?

Does the consultant have time to accommodate your schedule if he/she is really busy?

And I promise you: There will be questions after the fact, no matter how flexible the plan is (in fact, you may find that the more flexible the plan is, the more questions that will arise down the road).

You're likely to find that questions/consultations "after the fact" are going to be costly, both in terms of the consultants hourly cost and in terms of time spent doing back-and forth between the consultant and the development team.  (If you want to get the consultant and the dev team talking to each other, not only do you have to pay for both their time, but you have to ensure their discussions are productive and accountable.)

The potential for miscommunication here is manageable, but noticeable.

Let's review the pros and cons of this option, shall we?

Pros
  1. A solid roadmap that can be used to guide the implementation of your project and help ensure its success.
  2. Quick to "hit the ground running" for getting the project started.
  3. Very likely going to cost less over the lifespan of the project (see the caveats above).
  4. Accountability from vendors.
Cons
  1. After you have the plan, additional questions and consultations with the consultant will cost (probably by the hour).  If the consultant is busy, finding time to schedule you in might not work with your own schedule.
  2. Time spent in back-and-forth between the consultant, yourself, and/or the development team can cause frustration, lost time, and additional financial costs.  (This is what I like to call a real "time vampire").
  3. If the development team decides to take liberties/assumptions with the plan given, because they might not have the insight that the consultant has, it could subtly steer the project in a direction slight off-target.  Enough of these "liberties" can derail a project entirely if left unchecked.
  4. If things do go wrong, the blame game makes a serious appearance.  Who's to blame?  The consultant?  The development team?  Some combination thereof, and if so, how do you address the issue?  If this does happen (and it can/will), you will spend a lot of time running around between the two sides to get to the bottom of the issue.  It's not an A&E-type of situation (i.e. that's not exactly time well spent).
It's clear to see that this option immediately seems at least a bit more appealing than the previous one.  Gone is a lot of the time spent before the actual project can get moving, as well as a good portion of the overhead costs.

Things could still be improved upon, though.

Synopsis
This option is a traditional scenario for many projects of varying sizes.  It clearly helps mitigate time and costs while helping to ensure a successful project.

It also outlines what I refer to as a classic consulting situation; that is, the consultant offers advice only and no further services.

The largest concern coming out of this option is the disconnect and/or lack of direct contact between the consultant and the development team.  The project can still succeed, but we put at risk the projected cost (i.e. we're likely not minimizing our projected expenditure as much as we could) as well as the quality of the work (miscommunication and "broken telephone" can easily make a project suffer).

Next Time...
...we'll address this concern in the next post of this series as we look at what I consider to be an example of a modern consulting solution, which can add considerable value to a project such as this one.

Tuesday, 15 May 2012

Modern Consulting vs. Classic Consulting: The Sequel!

Previously, on the Mad Grapher
(Or maybe I should start off with "today, on a very special Mad Grapher..."

Ah, the things you can get away with on the internet!  But really, every post on this blog is very special!  And not in a patronizing kind of way, either.)

Last time, I described BHS Consultants as an "IT/technology consulting firm".  I also stated that it's a bit of a challenging label for the business.

In this post, we'll continue investigating the differences between what I call "classic consulting" and "modern consulting" by way of a (fairly short) thought exercise.

Recap
The situation we're considering is as follows:
  1. You are in charge of a large project to implement a new business process that is to be heavily automated.
  2. You have a fixed budget and deadline.
  3. You currently do not have the expertise or staff to undertake and complete the project.
  4. You want to make as big (read: positive) an impression as possible.
We are going to consider three options to accomplish this, as described in the previous post.

Let's start with option 1 (seems to be the most logical starting point).

Option 1

Find and take on an internal staff (either full-time or contract) including both SMEs (Subject Matter Experts) and implementors.

If you've ever had to hire and grow a staff, you know that it takes time to field the right people for the team--a long time.  Time, effort and money has to be spent tracking down those people (job postings, recruiters, etc.), not to mention screening and managing them (sure, you could always hire managers--and you'll probably have to for a sizable project--but that's yet another line item in your budget).  Headhunters can also charge a small fortune and their success rate varies at the best of time.  Tack on to that annual salaries, the cost of benefits, vacation days, sick days, turnover, etc. ad nauseum.

Yes, you'll likely have a greater degree of influence and control (some will also argue that your employees will "care" more and are more likely to provide buy-in; I don't necessarily agree with that point), but you'll have a lot of extra costs to carry (even for contracted employees which have similar costs associated with them).

If your office infrastructure is anywhere near capacity (or even if it's running at an optimum rate), adjusting for an influx of staff can add serious costs here, too.  

So on top of the pressure to complete your project, you have the added pressure (and time and cost) in hiring your own staff.

(From 20th Century Fox's Office Space)
Plus you might end up with this guy.  Poor Milton...

Let's summarize what we've seen with this option:

Pros
  1. Greater control and influence over resources.
  2. Possibly greater buy-in/"caring" for the project and its success by your resources.
  3. Makes some degree of sense for longer-term projects that require ongoing support.
Cons
  1. Lead time and spin-up time to get the team fully staffed and firing on all cylinders.
  2. Significant overhead costs.
  3. Dealing with HR-related issues (sick days, turnover, etc.).
  4. Possible infrastructure costs to accommodate new/growing staff.
I state point #3 in the "Pros" section because it does hold some water; however, this can be a difficult determination to make without doing some analysis in terms of the projected lifespan of the project (and its support) versus the cost of upkeep.

Synopsis
For companies engaging in longer-term projects that are close to its set of core competencies, this option does hold some merit.  But in an ongoing attempt at trying to improve bottom-lines everywhere (not to mention meet ever-tightening deadlines often created by the impression that technology magically speeds everything up), this option isn't as attractive as it once used to be.

Option 1 is a typical situation where a consultant will try to introduce himself/herself to help advise and guide the project along in the attempt to make the process as smooth as possible.  We'll see in the coming posts how a consulting firm engaging in modern consulting compares to the firm engaging in more traditional classic consulting.

Next Time...
...we'll investigate Option 2 where we see how a classic consultant would improve upon Option 1.

See you next time!

Modern Consulting vs. Classic Consulting: Part 1

Welcome back, all you graphanatics (oooh, I like that term; think I'll use it more, even though this post isn't about graphs)!

In my last post, I'd mentioned that BHS Consultants is an "IT/technology consulting firm"; I also mentioned that I'd discuss why this is a challenging label for a company such as ours.

Over the next couple posts, I'll be taking you through a more detailed examination of why that label is a challenging one for our company by way of comparing and contrasting what I call "classic consulting" and "modern consulting".

(I fully expect some people to disagree, and, as always, I welcome any/all constructive feedback and opinions.)

Classic Consulting

Classic consulting typically consists of offering expert knowledge to those companies that need to improve/implement a process, reduce/eliminate existing problems and challenges, and/or otherwise lend guidance to expertly guide a project.

Notice the emphasis on process and advice; there is no actual implementation work or "getting your hands dirty" in that respect.  (Peter Block, author of Flawless Consulting long-time consultant, hammers this point home in his book.)

Now I'm sure some (if not many) out there will either take exception or outright disagree with my definition above, and that's fine.  It lends credence to the fact that even classic consulting is a difficult animal to clearly define.

There's also the associated stigma that has traditionally been associated with the business of consulting.


We've all heard this one before.

And believe me, I've come across my fair share of other consultants that would do little but state the obvious and prolong any problem/contract for as long as they could in order to bill for more hours.

Personally (and professionally), I believe if you're not adding significant value as a consultant, then you have no place doing the job.

"Modern" Consulting

Not to be confused with Activision's Modern Warfare video game series.

In his book The Consulting Bible: Everything You Need to Know to Create and Expand a Seven-Figure Consulting PracticeDr. Alan Weiss (a very successful consultant in his own right) states--for all intents and purposes--that consulting is a "noble" profession and if you're another set of hands helping on a project (again, actually "getting your hands dirty" with implementation), then you're not a real consultant.

So we now have two authors and extremely successful consultants who have clearly stated their definition of what consulting is (and is not).

I'm going to rock the boat a bit here and say the following:
Modern consulting has adapted to meet the increasing demands of clients and must continue to do so in order to remain relevant and useful.
To be clear, I'm not saying that the principles and hallmarks of classic consulting are moot and no longer relevant; far from it, in fact.  Modern consulting builds off much of the foundation of classic consulting.  In essence, modern consulting expands the purview of classic consulting and removes many of the traditional boundaries between advising clients and actually performing implementation.

At the heart of consulting, to be sure, as many experts have written (including both Mr. Block and Dr. Weiss), is to have your advice actually used.


This definition of modern consulting is especially true in the field of IT and other technology-based fields (of which there are an ever-increasing number).

Consider this: You're put in charge of a large project to implement a new internal business process that is to be heavily automated, and you (and your superiors) know that no one in the organization has the know-how or experience to approach this project on his/her own, let alone the manpower to actually carry out the implementation.  What's more is that you're given a deadline (as is usually the case; how far in the future the deadline is doesn't factor in) and a budget (as is also usually the case).

As the person in charge of this project, you clearly want to do the job well and make a big impression on your superiors (there could be a bonus, a raise, or a promotion in it for you).

The best way to make such an impression is to achieve the following goals:
  1. Complete the project on-time.
  2. Complete the project within (and preferably well under) the budget.
  3. Complete the project with a high degree of quality.
(In my experience, in the worst case, if such a person can only achieve one of those goals, it'll usually be #2 as it's easier to make a good impression when you're able to point to a contribution to the bottom-line.  This is unfortunate, but sometimes necessary and it does happen more frequently than it should; remember, as consultant--classic or modern--your job is to get your client to listen to you.  If they don't, then there's little you can do about it, and you have to be prepared to accept that.)



I think we're all familiar with this model.

So, you have choices--some of them less desirable/applicable than others.

  1. Find and take on an internal staff (either full-time or contract) including both SMEs (Subject Matter Experts) and implementors.
  2. Find and contract a knowledgeable consultant to advise on the project and then either field a staff to implement or contract out the work to another firm.
  3. Find and contract a knowledgeable "one-stop shop" that has both the SMEs needed and the manpower to carry out the plan/advice from the SME(s).
There may be more options, but these are traditionally the three decision-makers and senior managers are faced with.

Next Time...
In the next post, we'll examine these three options in more detail.

(If my blog had a cool "Next Time, on the Mad Grapher" teaser trailer, I'd insert it right here.)

See you next time!