Project Management Tools | Want Quality? Use the “B” Team.

Want Quality? Use the “B” Team.

You have a big project. Critical to the company. So you put your best people on it. The “A” team. Funny, you always seem to get the same results. If your company is not doing well, your “A” team still results in you not doing well. Often, I attribute this kind of consistent pattern to a cultural or major organizational issue that needs to be resolved.

This organization or cultural issue is usually centered on a specific set of people. This set of people will often be your “A” team. If over a period of time your “A” team has been infected with folks that look and sound good, but can’t seem to cause the company to perform, it might be time to let the “B” team have a shot at it.

Let me provide a few examples.

The Client Has No Server.

We had two teams. The primary team was to take a purchased software client and embed it in the product. This was to be the premier product and was already committed to by a customer. The second team was a bunch of contractors, who we had worked with before, and who had provided a super low bid on working on a second client software package. This one was in fact our own client software developed by another part of the organization.

The “A” team worked through the process as we always had. High visibility. Lots of explanations for why things were hard and not always working well. The development process was a review each day of the “panics” in the software. It was development by solving successive failures in the code. Long, painful, late and typical of the organization as a whole. The customer, probably due to contractual reasons, “accepted” the late product and then only bought the minimum amount.

The “B” team was in a lurch. They didn’t have access to the server that the client on the product was going to access. This was their fault in bidding for something they didn’t have nailed down. It was our fault for accepting the bid when they didn’t have all the pieces in place. It was, however, a typical risk one takes on accepting that the contractor can put all the pieces in place. But boy, were they cheap.

The project went for a long time without the ability to test the client software in a live environment. The “B” team poured over the specs for the client/server protocol and wrote many “simulators” and otherwise inserted “messages” into the client to test it.

Finally, we could do no more; we needed to test with a real server. We relocated the team literally around the world and co-located them with our server team (why we didn’t just do this from the beginning is a good question – but it was one of those problems that would be fixed “next week – we promise.”). It took us about 24 hours to set up everything and get everyone connected. We then finally flipped the switch to see what happened. First try, nothing seemed to work. OK, double check configuration and settings, make some changes. This went on for a few hours. Suddenly, messages started to flow. It was working. It worked. The “B” team development manager sighed out loud (in heavy Russian) “There was no magic. It worked as we expected it to work!”

The “B” team took a lot of heat for not doing it the way the “A” team did it. The most humorous event was when the product team was livid that the “B” team didn’t know how to use our specialized tools to debug panics in the product. How could they not know something that was so important and so essential to the development process! It was humorous because the “B” team didn’t have all the panics that the “A” team did. They spent their time looking at the specs and the code to see that things were going right. They ended up not needing to run these specialized debuggers on the product because their software wasn’t constantly panicking.

The company eventually shipped millions of products with the “B” team’s solution in it. The “A” team’s software just faded away from non inclusion in any further product.

The Low End Product.

We had two products. Primarily, we were to take two existing products and add a new key feature to them. A feature that allowed the products to access the Internet about 10 times faster. The “A” product team took the high end product and the “B” product team took the low end version of the product.

I got pulled in to help the “B” team when they lost their project manager. I spent about 3 days talking to everyone on the team. It was a well managed product but with one outstanding issue. The software defects reported in the product were being fixed about 3 times slower than a typical product (21 days on average versus 7 days for a prime product). The defects were getting consistently fixed, just not quickly. In one meeting that included the test team, account team and product team, I heard an amazing comment: “If this is all the problems this product has, we are in great shape.” I never heard that before or since in this company.

What happened? The “A” team product was never successful. It was just another low volume product we had in our line-up. The “B” team product? First off, we already had a world class killer product on the market that changed how the world looked at these kind of products. It sold like crazy. We then had all of our other products. They looked like little blips next to the world class product. Well, the “B” team product never took the world by storm, but it was the 2nd best selling product after our world class product. It stayed that way for a long time.

The “A” team did all the normal things. It was a highly assertive team that generated lots of noise and got lots of attention. Everything that was wrong with the product was specifically because of something the development team did not do right. It was not successful because of failures in development. The same development teams worked on the “B” team product. They were not challenged and driven constantly. They did not spent all their meeting times with dueling power point slides showing what they did and defending against product team claims.

In both the above cases, several things stand out:

1. The “B” team was populated by folks that the organization did not see as their best people. They were good people but not folks you put on your most visible products.
2. The “B” team did not follow the typical processes. They usually had to beg, borrow and steal the time and resources they needed to move their products forward. They were happy when someone worked on their product or gave them resources. They also didn’t have much “pull” at forcing folks to work more or harder on their product.
3. The “B” team products were distinguished by high quality when compared directly with related products. Their schedule performance was as good or better than the “A” team products.
4. The “B” team products sold better and lasted longer than the “A” team products.

One could look at this as just luck or otherwise not typical. However, if you think of the “B” team as similar to a skunk-works or other low visibility effort, then you might get a hint at why they are often successful. As long as the folks doing the work are motivated and good at what they do, then I think you will find you will get similar results. In this case it was a Fortune 50 company who had attracted a lot of good people. The “A” versus “B” team was often a personality or perception based division where certain folks had succeeded in convincing the organization that they were the ones to rely upon for success. The major ability of the “A” team, it would seem, was to grab key products and make lots of noise. It was not the case that they performed the best when objectively compared to the “B” teams.

Take a second look at your “B” teams. They might be the silver bullets you need now.  (See related: “Silver Bullets – Project Management Tools That Work“.)

Filed Under Change Management | 9 Comments

Tagged With Change Management, Productivity, Project Management, Project Management Tools, Quality, Schedule

Comments

Solutions

• Subscribe To These Articles

• Tools, Techniques, Hints & Tips

  • The Most Effective Part of the Day In Project Management?
  • Project Managers Repeat After Me: Software Development Is A Repeatable Process
  • Improving Project Management Productivity Does Not Save Time
  • One Reason To Always Support The Other Guy’s Project
  • Don’t Squash Your Project Management Pockets of Excellence
  • Don’t Kill The Golden Goose of Project Management – The Crisis
  • Project Management Crisis? Hurry, But Do Nothing
  • Project Management Initiative or Insubordination?
  • Your Project Needs Business Rules, Not Meetings
  • Project Management Or Anesthetized By Analytics?
  • Project Management or Death by Detail?
  • One Key Secret for Improving Project Management – Just Do It!
  • In Project Management 9+3 Is Not Equal To 12
  • The One Perfect Project Management Methodology
  • Three Reasons Not To Finish A Project Early
  • One Way To Make Your Project Risk Free?
  • 2 Ways To Make Project Management Problems No Big Deal By Managing Risk
  • 3 Secrets For Successfully Putting Your Project Management Team At Risk
  • Don’t Get Everyone Project Management Certified … For The Wrong Reason
  • One Great Way Of Using Your Project Management Staff Hours
  • Four Insights Into The Best Use Of Your Project Management Experience
  • Fixing The Project Management Plan: What Should We Be Doing?
  • Visibility – The Fifth Project Planning Secret
  • The Official Plan: Four Project Management Planning Secrets
  • Yes Virginia, There Is A Project Management Plan
  • Get Out Of The Rut Of Solutions That Don’t Work!
  • You Really Can Know If Your Project Estimates Are Accurate
  • Your Team Really Can Do A Great Job
  • One More Way To Fight E-mail Infoglut: Talk!
  • Don’t Treat Your E-mails As Dead Skeletal Husks!
  • Five Techniques For Overcoming E-Mail Infoglut
  • Using Hard Facts To Reduce Honesty Buffers
  • Nine Ways To Eliminate Honesty Buffers
  • Eliminate Your Project Management Honesty Buffers
  • Focusing On High Quality Gives You High Productivity At No Extra Cost
  • Project Managing Climate Change And Your Kids On Blog Action Day
  • It Should Work The First Time
  • Getting The Schedule Right Is Hard! But Not For The Obvious Reasons.
  • The One Key Step For Successful Improvements
  • The Busiest Software Test Organization Was Also The Best
  • Almost a Great Software Test Organization
  • Want To Stress Your Test Team? Give Them Good Quality!
  • Is Your Project Management On Steroids? Maybe You Should Kick The Habit!
  • Disrupt The Project To Make The Big Improvements
  • Project Management Needs Business Intelligence!
  • Global Project? Farther Away Can Be Better!
  • Are You Managing the Critical Project Thread?
  • Want Quality? Use the “B” Team.
  • Successful Projects Are Boring!
  • A Successful Manager But Never A Successful Project?
  • Project Managers, Are You Being Heard?
  • Does Anyone Really Care If Your Project Is On Time?
  • Is Your Project On Time?
  • The Ultimate Project Management Tool
  • Meeting Madness? Don’t Do it!
  • Seven Ways To Make That “Silver Bullet” Work
  • Avoid This Project Management Schedule Trade-Off Trap!
  • Knowing Your Project Management Average Is Powerful!
  • Being Slightly Out Of Control Can Be A Good Thing
  • The Leap From Mediocrity To The Exceptional Is Shorter Than We Think
  • Don’t Project Manage Change – Provide A Service!
  • Defect Reports Are Your Best Friend!
  • Get the Schedule Right!
  • If Nothing Else, Honesty Is Just More Efficient

• Browse by Category

  • Change Management
  • Communication
  • Personal Practices
  • Planning
  • Reporting
  • Risk Management
  • Schedule
  • Testing
  • Time Management

Tags

Change Management Communication Defect Arrival Rate Curve Defects E-Mail Estimation Honesty Honesty Buffers infoglut Initiative Measurement Metrics Military On-Time Productivity Project Communications Project Management Project Management Tools Quality Reporting Schedule Software Software Defects Time Management Tracking

• Recommended Resources

  • Blog Catalog
  • Blog Flux Directory
  • Blogged
  • Business Blog Directory
  • Cloud Computing
  • Customer Service Helper
  • Financial Project Management
  • Project Management Center
  • Search Open Directory
  • Software Engineering Institute
  • Softwarebuzz – Tech Blog
  • Spam Mail
  • Tom Peters
  Get subscribers