HAS THIS EVER HAPPENNED TO YOU?

Project Kick-Off

• Vendor: “This is Raj, he is going to be your Technical Lead for your project, and he is our best Consultant with these types of Solutions.”
• Me: “That’s fantastic, pleasure to meet you.”
• Vendor: “And the other team members are just as good.”
• Me: “Great, I can’t wait to get started.”

And the Project gets kicked-off and best of all it seems like you have a Real “A-Team” of 10 top consultants, so it absolutely will be a success.

‍

Then Two Months In

Everything seems to be going well and things seem to be on track.  However, most of the time Raj is often absent from meetings or unavailable when you want to speak with him about a technical aspect of the Project.

• Me: “I’ve been trying to reach Raj, to discuss this aspect of the Project with him.  And I’ve noticed he’s been absent from some of our joint team meetings, is he Ok?
• Vendor: Everything is fine, I will talk to him and make sure he is available for you.
• Me: “I’m glad to hear that.”
  

‍

Approaching Milestone #1

As you are approaching Milestone #1 - you are starting to see delays in the Project, as well as significant Quality issues with the code output from the Team.

• Me: “Where is Raj?  I need to speak with him about several concerns that I have.”
• Vendor: “Well unfortunately, Raj has been transferred to another Client.  We have identified another Team Lead, Katia, and she will start next Monday.”
• Me: “What?  Why are we switching Team Leads in the middle of the Project?”
• Vendor: “I don’t know the exact reason, but trust me Katia will be a very good Tech Lead for you.  She has already been shadowing Raj, so she can pick up where he left off very quickly.”

‍

Approaching Milestone #2

Milestone #1 was late by over a month, and now…

• Katia is Ok, but not Great.  She tries hard, but seems to be lacking experience.

• Other Team Members are being rotated out, one at a time each Sprint, and replaced by someone new:‍
• We just lost our Agile Scrum Master.
• And two more Developers.
• And our QA Engineer.

• In ONLY 6 Months, we’ve had a 50% Turnover within our Team.  WTH.
• And every time they swap out Team Members, we lose ground and our schedule looks worse and worse.

‍

RED ALERT - after 9 months

• Me: “This is not going to work, if we continue down this path.  We are 3 months behind schedule, and now we only have 2 Team Members who have been on this Project since the beginning.  How are you going to fix this?”
• Vendor: “I understand you are upset, and to make sure we can deliver things on time fortunately Rav is available and we will have him work with Katia to get the project back on track.”
• Me: “This is your last chance, so Make it Happen.”
  

And “Rinse and Repeat”, until I had no option but to fire the Vendor, and find someone else.

‍

David’s Sidebar

1. Yes, this actually happened to me as a VP Software Development for a Publicly Traded Company (NYSE:  UTI).
2. And for the record, I’ve personally been involved in many different Offshore / Nearshore / Consulting Organizations throughout my career - including being on both sides of the “Coin” as either a Partner or as a Client.
3. Unfortunately, once I fired the Vendor - and the timeframes were pretty close, we could only actually use 11 very minor features that they had developed.  The rest was thrown away, resulting in a CapEx write-off of approximately $550,000.  The original budget was for $575,000, so we had to write-off or take a loss on most of this project.
4. I personally wanted to kill the Project much sooner, but our CIO at the time insisted on trying to make it work.

‍

Dedicated Teams vs. Transient Teams / Staff Aug

Within the Consulting and Off-Shore / Near-Shore Industry there are several Business Models that companies use.

‍

Staff Augmentation a.k.a. Body Shops

Within these Firms what you are doing is “Renting” a person or persons, who supposedly have a specific skill, knowledge, or talent, to perform work for you.

This is akin to standing on the Street Corner and either flagging down a Taxi Driver or waiting for your Uber Driver (whom you’ve never met) come and pick you up.

• Are they a good driver? Maybe / Maybe Not.
• Will they get you to your destination? Yes, eventually.
• Will they get you there on-time? Uncertain.
• Can I fire them? Sure - just ask the Driver to pull over, get out of the car, and wait for the next Taxi / Uber Driver to come by.
• Likewise, if they don’t like you, they can stop the car and ask you to get out.
  

In most cases, these Consultants are actually Independent Contractors, with no loyalty to either the Company they work for, or to you as a Client. They are only there to do a job, that’s it, nothing more.

And if the Project starts having significant challenges, or they get a better offer somewhere else, most will simply leave. They don’t want the stain of a failed project on their record and money talks. Just keep in mind that an Independent Contractor is always looking for their next “Gig”. Naturally, I’m generalizing and not everyone does this, but it is fairly common.

In general, you will have a better experience if the individual Consultant is actually an Employee of the Contracting Firm. Because then they will have more control over the individual, and use benefits, training, and bonuses to entice the individual to stay.

PROS with Staff Augmentation

• Best for Short-Term Engagements.
• Typically lower Costs - no or little benefits or other overhead.
• Can Fire / Hire / Replace at any time.
• Can Shut the Engagement down any time you want.
• Ability to Request a Consultant with a Specific Skill Set.

CONS

• Potential for Very High Turnover.
• No or very little  loyalty to the Contracting Agency or You.
• Just waiting for the next “Gig” to come along.
• Project Challenges / Disagree with a Technical Approach - I’m bolting, on to the next “Gig”.

• All of which can lead to:‍
• Project Failure.
• Project Delays.
• Additional Costs / Cost Overruns.
• Loss of Tribal Knowledge about the Project.
• Lower Team Productivity / Velocity.
• Lower Team Morale.

• Do they actually have the Skills / Knowledge / Abilities they claim?‍
• Are you getting a Super Star Driver?
• Or the Taxi Cab Driver from Hell, who causes an Accident - destroying your Project and Plans?
• You never know.
• When in doubt, Replace Soon and Often.
• Or better yet, consider a Different Approach.

‍

Team, Team, Team… Here is Your Team… at least for the Moment

Unfortunately, there are many Professional Services Organizations, Consulting Organizations, Off-Shore / Nearshore Organizations, which will “Sell” the concept of a Team, but in actual practice it doesn’t work that way.

Their Modus Operandi is the following:

1. Early on, assign some of their Top “A” Consultants to the Project.
2. Within a month or two, start replacing these individuals with other more Junior / Lesser Talented Consultants.  They need to do this, because they just “Closed” another Deal, and need their “A-Team” to kick-off this New Project.
3. Several months later, unbeknownst to you some of those “B” Consultants are now needed to back-fill the A-Team on Client #2, so your “B-Team” is slowly replaced with new “B” or even “C” Consultants.
   

This continuous churn becomes a real problem, as even the very best Developer, Project Manager, Business Analyst, QA Engineer, etc. can take months to reach 100% Productivity and Effectiveness.

PROS

• Better than pure Staff Augmentation - at least you are renting a Team, sort of.
• Typically lower Costs than Dedicated Teams.
• The team members normally work directly for the Consulting Company, but not always.
• Better loyalty for the most part.

CONS

• “Bait and Switch”:
• They Bait you with the thought that the “A” Team will be yours.
• And then Switch the team out over time for the “B” Team.
• And maybe even Switching it out again for the “C” Team.
• Thus, over time you get poorer and poorer quality Resources, until you complain - as which point you suddenly get assigned a higher level Resource.
• But once the Project is stabilized, they go back to their Standard Operating Procedures.

• Lower Productivity / Velocity due to Turnover:
• You are constantly setting up new Consultants on the Tools / Dev Environments / Access Rights, etc.

• Technical Decisions Made Earlier / Can be Unmade Just as Quickly:
• You just spent months working with the team on a Technical Approach, and the entire Team agreed to it.
• Then suddenly your “A” level Tech Lead, leaves and is replaced by someone else.‍
• “B” Tech Lead either doesn’t know how to do it “A’s” way.
• Or thinks they have a better approach.
• So, the team spends weeks ripping out and replacing code.
• NIH (Not Invented Here (by me)) Syndrome - so since I didn’t invent it, there must be something wrong with it.

• All of these things can end up causing:‍
• Project Delays.
• Cost Overruns.
• Reduced Functionality / Features.
• And even Project Failure.

‍

Dedicated Teams

In these organizations, they sell a Client a completely dedicated Team or “Pod”, which is assigned to the Client / Project for the entire duration.

In addition, all of the Team members are actual Employees of the Professional Services Organization. And as such, they are better cared for by their company, have better benefits, continuous training, and are more loyal to both the Company and the Client Projects they are working on.

Once the Dedicated Team is assigned to your Project, the team members rarely change, but it can happen. And the reasons are no different than if they were your own Employees (a sudden opportunity, a request to move to a different team, health issues, etc.). The other benefit with a Dedicated Team, is that over time you can get to know them as individuals and even treat them as an extension of your IT Department.

On multiple occasions, when I have been on your side of the coin as a CIO or CTO, and I had a Dedicated Nearshore Team over a period of several years, we simply included them in all of our Technology Strategy Sessions and even Business Objective Planning, they were just another portion of our IT Department.

And the more they learned, the more they were able to bring new ideas and concepts to the table, greatly increasing the value they added to our Organization. That is when you know, you have a true Partner.

Naturally, there are both Pros and Cons with this approach.

PROS

• IF you treat them as part of your IT Department, THEN:
• They will respond in kind… and Act as Though They Work for You! They will:‍
• Collaborate with you on new ideas, concepts, projects, modules, features, technical approaches, etc.
• Tell you when a Project shouldn’t be done, and why.
• Advise you when you are going down a technical path that may not work, or is not the best choice, and why.

• And to do this and get the Most Value from your Dedicated Team:
• Send them Polo Shirts with your Company's Logo on them.
• Send them a Company Flag or Banner that they can hang up in the office.
• Invite the leaders on the Team to your Company Retreat and Planning Sessions.
• Invite some Team Members to visit your facilities, in order to learn about your business.

• Higher Team Productivity over the long term:
• More Software features and functions produced.
• Often fewer Defects / Bugs.

• Better Architectural decisions - this isn’t a short term project for the Team, they want to do it Right.

• Loyalty and Dedication:
• There were several times, when I had to personally ask my Dedicated Team to work Weekends or Nights, when we had a Critical Deadline or Go Live Date.
• And they did it, every time.
• Often with Dedicated Teams, you are not charged extra for this overtime work, as long as you don’t go crazy and expect this all the time.

• Just as if they are your own Employees, it is easier to have a conversation with the Team Leads, if someone is falling behind or not pulling their weight:‍
• Health Issue.
• Family Issue.
• Performance Issue.
• Something else?
• You can work with them, as you would any of your Managers, to come up with the best approach to address whatever is going on.  Again focusing on the Team and treating them as you would your own Employees.

CONS

• ELSE if you don’t treat your Dedicated Team as part of your extended organization, and you treat them as only a “Vendor”, then you really won’t gain all of the Benefits.

• Costs may be slightly higher than other options, BUT:
• This varies greatly upon where in the World your Dedicated Team is based.

• You are putting a lot of Faith in your Dedicated Team by treating them as part of your overall IT Department.  While you have the same Risks with your own Employees, you do need to put in place appropriate Controls and Policies:
• Administrative Rights to Applications.
• Data Security.
• Access to Production Systems:
• Who can do what?
• Under what conditions or situations?
• What can they do and/or change?
• What is logged, so it can pass a forensic audit, etc.?
• Are they even allowed to access certain types of Data due to Regulatory Compliance Issues.

We hope that you have enjoyed this Blog Article and have found it useful. Thank you.

- David Annis