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.
Comments