Picking the Right Project Team

by Kent McDonald

While at the Agile 2007 Conference a couple of weeks ago, a project manager from a small development shop tracked me down and asked me the best way to organize their development organization. Not being a big fan of the word "best" (what works really well in one situation is quite average in another, hence making "best" very context-specific) I threw out my standby consulting answer: "It depends." Then I asked some questions about their organization and what kind of work they typically do. Based on that, I provided them with some context-specific suggestions.

Afterwards, I thought that there are probably others who have the same question. So, given the caveats listed above, here are some thoughts on how to organize your organization to undertake development projects.

Since I can't possibly know under what conditions readers of this article are working, I thought it best to describe some general characteristics usually exhibited by successful project teams, and provide ideas for adopting these characteristics.

The PAC Principle

Whenever possible, you want to make sure you have the right people on your team. So who are the right people? They are the ones who:

  • want to be on the project,
  • have the necessary skills to appropriately complete the project,
  • and have the time available to focus on the job at hand.

I refer to this as the PAC Principle: Passion, Ability, and Capacity.

You want people who have some passion for the project on the project team. These are the folks that have an interest in the business problem being solved and/or the technology being used to provide the solution. Passion is probably the most important of the three because (as I have learned from personal experience) if you don't enjoy what you are doing and have a burning desire to keep doing it, chances are you are going to use about a fourth of your ability, and you will end up wasting your capacity on things you would rather be doing.

You want people on your team that have the ability to do the work that is required to successfully complete the job that needs to be done by the project. I'll talk a little bit later about how concentrated those abilities should be, but the thing you want to remember is to make sure that each person on the team contributes some ability to the overall team. After all, it does not help overall team dynamics to have dead weight on the team.

Once you have people that want to do the job (passion) and can do the job (ability) you want to make sure that they actually have time to do the job. This is capacity. Say all you want about productivity and the near-hero status we place on people who are able to do multiple things at the same time, the truth of the matter is that people who are trying to focus on more that even a couple of things at the same time end up wasting more time on context switching than they do on getting work done. If you team does not have the proper time to focus on what they are doing, they can have all of the passion and ability in the world, but they still are not going to be able to focus and do a very good job.

The Renaissance Project Member

Now that you know your team exhibits the PAC principle, you want to make sure that you have all of the skill sets necessary to do the job well. In most traditional software development settings that would mean that the project lead assumes that they would need to go out and find a few developers, usually a different one for each type of technology needed for the project, a business analyst, some testers, a DBA, a technical writer, a designer, perhaps a data modeler, and a various and sundry other specializations that seem in vogue at the time.

It's great to have all of these specialists on the team because from an ability standpoint, all the bases are covered. The trouble is that the "bus factor," as I refer to it, goes way up. The bus factor is the measure of how reliant a team is on the knowledge held by only one person, i.e. what would happen if George got hit by a bus. (I know, there is probably a less morbid way of expressing that idea, but it gets the point across.)

Having a lot of specialists also results in plenty of potential bottlenecks because all tasks of a certain kind have to be done by one or a few people, so at certain points in the project certain people are really busy and others are twiddling their thumbs. In other words, the project team has a very bad capacity balance.

Finally, the more specialists you have on your project team, the more likely is the need for several handoffs, where one person can only take the job so far before handing it off to someone else to finish. This not only results in extra work in the form of intermediate documents, it will also tend to create communication barriers because people adopt the attitude that, "Well, I designed the database model. It's Fred's job to actually build it."

Don't get me wrong, you need to have all of those skills on the team. But they don't have to reside in a bunch of different people. Scott Ambler introduced the concept of the generalizing specialist which, simply stated, is a jack-of-all-trades and master of some. These are individuals that have a few specializations at which they are very good, but have the ability in several others to do a sufficient job. The ideal is to have a project team made up of generalizing specialists that cover all of the skills needed for the project.

On a team made up in this fashion, the people with specializations in a certain area can mentor others in those areas to get them up to speed. This means that you are not reliant on one or a few people to do a particular task, which allows the team to shift around and put all hands on deck to do whatever tasks are important at the time. This also results in a more well-rounded project team that will tend to need fewer intermediate handoffs, because chances are they have been engaged in the project from the beginning, so they don't need that information handoff. Finally, your team will be more likely to be innovative and high performing, because you have a team full of people who are willing to learn new things and expand their horizons.

Gelling Team

"Are you Gellin" is more than an slogan for a shoe insert; it's also a good way to measure the effectiveness of a team in your software development organization. You can have a group of people that all have PAC, and you can have a bunch of people that can all do everything if they put their mind to it, but until they work well together the whole will rarely equal, let alone exceed, the sum of the parts. Alistair Cockburn identified seven characteristics of successful projects in his book Crystal Clear: A Human-Powered Methodology for Small Teams. Three of those characteristics speak directly to the concept of a Gelling Team.

  • Reflective Improvement: a team that is constantly looking for ways to improve how they are achieving the goal of the project
  • Osmotic Communication: team members are able to communicate so naturally with each other that they almost get to the point of completing each other's sentences
  • Personal Safety: team members feel comfortable enough with each other to speak the truth and occasionally throw out hare-brained ideas because there is an environment of trust and respect

Once you have a team exhibiting these characteristics, you are well on your way to having a Gelling Team, and one that will be fairly successful at delivering the intent of the project.

Unfortunately, these characteristics do not appear overnight. Dr. Bruce Tuckman identified the five stages of development teams go through: Forming, Storming, Norming, Performing, and Adjourning. A gelling team sits squarely in the performing sweet spot, but to get there you have to take the journey, and it can be somewhat painful. One of the project lead's main jobs is to help the team progress through those first stages on their way to performing.

Applying the Premise

So now that we know the characteristics that we want in our project team, how do we achieve that nirvana? Assuming you buy into the premise I describe above, you want to set up your organization to enable those things to happen. Again, the actual implementation will depend on a specific organization, but here is some general advice that should work relatively well in most circumstances.

Establish Centers of Excellence. Even though you want to have generalizing specialists, you still need some means of providing coaching and training for specific skill sets, and depending on the size of the organization you may want to develop organizational standards (as long as they are more guidelines that restrictive rules). Centers of Excellence provide a focused collection of knowledge on a particular skill set and are analogous to the more traditional BA Team and Development Team. These may also be the organizational units to which people are assigned for HR purposes. The trick to remember here is to not allow these units to degrade into a collection of specialists.

Build teams around a specific product or system. For HR purposes people report to a resource manager providing guidance on a specific skill set, but for everyday work they are organized into teams that are focused on a particular product (for software product companies) or system (for internal IT units). This style of organization provides a couple of advantages. First, it keeps a team together for an extended period of time, which allows them to reach gelling status. And second, it allows the members of the team to focus on a specific subject area.

Keep the passion alive. The problem with having product-focused teams is that the team could get to the point where they run out of challenges and start to lose interest in what they are doing. There are a couple of ways to tackle this.

First, if you have a well gelled team that has gotten the product to a completed state, move the entire team onto some other project. This provides the advantage of providing the team new challenges while at the same time giving the new project a head start by placing a well performing team on the project from the beginning.

Providing the team with the opportunity to learn new skills while working on the same project is another way to keep the passion alive, and it has the side benefit of extending the number of Generalizing Specialists in the company.

Don't be afraid to change seats on the bus. It may seem that I have an infatuation with public transportation, but here I am referring to Jim Collin's advice from Good to Great, where he describes great companies as those that are willing to make sure they have the right people on the bus (or off the bus in some cases) and in the right seat on the bus.

In the process of forming your gelling teams, you will find cases where you have someone that you want in your organization, but they may not necessarily on the right project—they are on the right bus, but not necessarily in the right seat. In other cases you will find people that frankly are not on the right bus. In those cases, you should get them off that bus as soon as possible, otherwise they will impact the performance of the team. If the rest of the team is truly performing well, they may very well help the team member off the bus themselves.

Provide the Right Environment

When thinking about organizational design, it all comes down to providing the right environment for your teams to be successful. Experience has shown that if your project teams and their members exhibit the characteristics described above, and your organizational design supports the emergence and sustainability of those characteristics, your projects will have a much better chance of success. When it comes down to actually implementing the organizational design, well that all depends on your particular circumstances. Give it a go. Oh, and watch out for those buses.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy