Project Management Screw-Up 6 - The Team Didn't Gel

Excerpted from The Project Management Advisor - 18 Major Project Screw-Ups And How To Cut Them Off At The Pass (Prentice Hall, 2004)

I played the drums as a kid starting in fourth grade up into college. My family suffered through many hours (and headaches) of me beating the skins to jazz, funk, and rock music. When I started playing with the school band, I had to learn that making music wasn’t about how fast I could do flam-a-diddles or how loud I could play, but how I played in relation to the other band members. If the music called for adagio (slow & leisurely pace) it would be a bad idea to break into an In-A-Gadda-Da-Vida drum solo while everyone else is playing elevator music. 

The important thing was to match my playing to the other instrumentalists and to make beautiful music together. While I never got to rock stardom with my own entourage and groupies, I did learn that music is about how the entire band sounds -- not any individual player.

By now you’re probably wondering why I took a mental trip to Tahiti to tell you about my musical aspirations. To me, a well-structured project team where each team member understands their role in making the project successful is like the musicians playing in a band. Each project team member knows what they need to contribute to the project, when they have to perform, what other project team members are doing on the project, and what it takes to be successful. Just as important, each of the project team members helps each other to ensure overall project success.

How it happens:

There was not a clear project organization with clearly defined roles - This goes beyond a hierarchy chart. Each person needs to know what function they play on the team, how they fit into the other functions, and what happens if they don’t do their job.

Depending on your industry or functional discipline, there may be standard or customary roles that you employ on your project. There are a few things that I have learned, though, about project standard roles as follows:

• Start with the standard or customary roles that are typical for your type of projects
• If the project need warrants a special role which is outside of standard, create a special role
• If the project doesn’t need a standard or customary role, eliminate the role
  
  

These may sound like overly simplistic statements, but I’ve been amazed over the years with seeing cumbersome project role structures because the project manager was reluctant to deviate from standard project roles. As experienced project managers, our job first and foremost is to make sure that the right people are assigned to do the right tasks to produce the right result at the right time. At the end of the day, I’ve never been graded on how well I adhered to a standard project role structure; I’ve been graded on results.

If the project environment doesn’t have standard or customary project roles or if I’m taking on a unique type of project, I like to take a very pragmatic approach to role definition, as follows:

• Define the 3-6 things on the project that I am most concerned about or pose the greatest risk to me
• Create roles that encompass the concern or risk areas
• Cross-check the roles with the work that needs to be done in the project schedule to ensure that all the major roles are being defined correctly
  
  

By doing this, I am addressing concern or risk areas head-on by defining a role with a singular point of accountability to manage the areas of my project that are most likely to fail.  This technique has helped me on more than one project to sleep better knowing that I had my most crucial areas covered.

The team finger pointed and fought in public - On any project you do, so long as there is more than one person involved, there are going to be lively discussions. When this happens, it is very likely that something good will come of the discussion and that in some way the project will move one step closer to the finish line as a result. On past projects I have managed, I was very deliberate about letting these discussions happen and in letting team members question each other. I did put a few rules in place, though:

• It’s very cool to challenge and stretch, but when we make a decision we need to get behind it as a team
• What happens in the room stays in the room; outside of the room we are a unified team
• If we made a wrong decision we accept the decision as a team; no finger pointing allowed
• We focus on the problem and not the person; don’t make the problem personal
  
  

So, were the rules followed 100% of the time? Sadly, no (myself included). After all, we are human. However, you should still strive to get some ground rules in place to avoid team strife where you can.

There was no “rallying cry” - You can look at many major successful campaigns and pull some slogans from them which embodied the message behind the slogan: “Where’s the beef,” “Milk, it does a body good,” and “Plop, plop, fizz, fizz” are all unifying messages that cause you to think about a product. Similarly, when driving a project it helps the team to have some kind of a rallying cry or mantra that the team embodies when driving work. On one project, we wanted to be extremely cautious of not over-designing a solution and putting too many bells and whistles in to help us keep our costs down. We started using a “good enough” rallying cry during the design phase to be a continual reminder that we wanted to not overdo the solution. It worked incredibly well because the team would critically question itself with “Is this good enough?” when looking at the architecture and functionality. Aside from helping to make sure that our solution was cost effective, the rallying cry helped the team to better bond.

Team members weren’t held accountable for delivery - With project teams, I firmly believe that each role needs to clearly understand what they need to do, when they need it done by, and how their work fits into the big picture. I also firmly believe the project team isn’t only accountable to the project manager, they are accountable to each other because if any of the other roles fail the entire team fails. Given so, it is vitally important for each role to be visible as to what each other role is doing for the following reasons:

• Each role should be continually looking at other work that is happening to ensure that they know if and how they fit into the other work
• Each role should feel that if they miss a deadline or do not perform their job adequately, they are letting down the team as a whole, not just the project manager.
• Meeting or missing deadlines and deliverables are a team issue and should be exposed to the team.
  
  

The point here is accountability. Each member needs to feel accountable for their work and needs to experience the joy of success as well as the discomfort of failure. The project manager needs to use discretion on making sure that things do stay constructive. Focus should be very much on how the team gets things back on track and moving forward versus badgering the team member.

In some instances, though, you may just have someone in a job who is not suited to perform. The project manager needs to deal with those situations swiftly because if he or she doesn’t, he or she is not doing his job nor being accountable to the team by dealing with a problem performer.

The project manager wasn’t suited for the job - The project’s needs and criticality to the business will be key drivers in the required experience level of the project manager. For relatively simple projects, you may be able to staff the project with an inexperienced project manager with a more seasoned project manager serving as an occasional mentor. As projects increase in complexity and criticality to the business, though, there’s no substitute for an experienced, seasoned project manager.

I’ve been incredibly fortunate to have worked with some outstanding project managers over the years. In thinking about the best project managers, they’ve had the following things in common:

• They knew the techniques of project management cold
• They knew (through experience) where they could bend the rules on the techniques to be able to buy time or be more efficient
• They always kept things moving forward
• They knew when to shift from “let’s discuss” mode to “let’s decide” mode
• They held others accountable to do their jobs
• They praised success
• They were excellent communicators
• They took the heat for the team when external criticism happened
• They were calm and focused when things started going bad on a project and everyone else was wigging out
  
  

I know of no magic formula for fitting the project manager for the job; what I can say is you’re better to err on having an over-experienced project manager versus an under-experienced one.

I knew of a very gung-ho young project manager (let’s just call him “Author”) who felt he was an outstanding project manager because he knew the techniques well (cost and schedule management, status reporting, and so on). Because Author knew the techniques, he felt he could simultaneously take on three complex projects that really should have each had a dedicated project manager. Not only did Author learn some very valuable lessons, he unfortunately also cost his company a lot of money because others had to come in and mop up his mess. Both Author and I can’t stress enough to make sure your project manager is suited for the job.

The team didn’t celebrate wins - Driving through a project is tough work. It is incredibly easy for people to get discouraged whenever the team hits roadblocks or has setbacks. It is vitally important for a team to celebrate hitting key milestones simply to keep morale up and keep project momentum. I’m not talking about three-day cruise type celebrations, it could be as simple as bringing in pizza or cake or something that allows people to let their hair down and take a bit of a breather. I would caution you about doing this too much; doing too much celebration lessens the effect of the celebration and could actually annoy your team members. I was on one project where people did not like the morale events because it only meant that they had to stay later that evening to get their work done. So, celebrate, but do it in moderation.

Warning Signs:

The team shows confusion about who is doing what - Confusion can exist either due to poor communication on who is responsible for what tasks or because tasks can reside under the responsibility of more than one role. It’s important not only to get people to agree on areas of responsibility, but to ensure that the responsibilities are clearly documented and communicated to the entire project team. Also, be prepared to pull this document out and remind the team of its respective responsibilities as confusion creeps back into the project team.

Discussions are destructive and unproductive - You know what this looks like; if you’re team can’t have discussions without getting personal, derogatory, or outright mean this is a pretty clear sign you’re not gelling as a team. The project team doesn’t have to be best friends with each other, but they should at least respect what each other bring to the table.

Team members aren’t helping each other - I’ve actually been in some environments as a consultant where some team members enjoyed seeing other team members fail and did absolutely nothing to help them for the good of the project. Project team members who carry an “every person for themselves” kind of attitude are not going to perform anywhere near their full potential.

Turning it around:

Clarify the confusion - Get team members locked in a room and hammer this out. If you get stuck on a particularly contentious area or if you see tempers flaring, set it aside and work on other things, then come back to the contentious area. Make sure that responsibilities are documented and clearly accessible for all members.

Address the problem team member - Never a pleasant task, but I on more than one occasion have had a project team member taken off the project because they simply were going to remain a destructive force on the project. At the same time, I’ve also been able to turn a destructive situation around. In either event, address the issue swiftly before it does further damage to the rest of the project team.

Co-locate the team - I’ve had some of my greatest successes where the project team was physically located in the same area and had minimal physical barriers to inhibit communication. This may or may not be entirely possible depending on your project, but where you have the opportunity to co-locate team members, strongly consider doing so.

Go out for a milkshake - Sometimes it’s great to just get people away from their work environment and socialize over a favorite food and beverage. As a consultant on out-of-town projects, our project teams were typically very effective because we had more time to socialize and bond during non-work hours. Getting to know each other a bit and being able to laugh as a team pays huge dividends in overall team effectiveness.

All work and no play…- ...makes for a really dull and demotivating project. Take some time out of the project to have a laugh. I have certainly been known to play an occasional practical joke on a project or to bring some occasional levity to a particularly stressful time in a project. Just be careful that the use of humor isn’t too excessive or inappropriate; but by all means make sure that you share a laugh or two even if it’s at your expense.

Be the unifier - As the project manager, you are expected to take responsibility for getting the team to gel and to know the barriers that exist which are preventing the team from being a highly cohesive, collaborative, high-performance team. At times, it’s likely to be the most uncomfortable part of your job, but it can also be one of the most rewarding when done well.

Take Aways:

• Define a clear project organization with clearly defined roles
• Be a team through thick and thin; don’t publicly finger-point when things start going south
• Develop a “rallying cry” which focuses the team on the mission
• Let the team members do their jobs, but hold them accountable for results and dates
• Make sure that you have a project manager that who is appropriately seasoned for the project
• Celebrate the wins as a team
  

Lonnie Pacelli
Keynote Speaker | Board Director | Autism Advocate | Author | Project Management Expert | Microsoft/Accenture Veteran 
See his books on Amazon.