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.