By now you’re probably wondering why I took a mental trip to Tahiti to tell you of 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, knows when they have to perform, understands what other project team members are doing on the project, and knows what it takes to be successful. Just as important, each of the project team members help 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:
If the project environment doesn’t have standard or customary project roles or if I’m taking on a unique type of project, then I like to take a very pragmatic approach to role definition, as follows:
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:
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 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 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 since 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:
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 are they 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:
Because Author knew the techniques, he felt he could simultaneously take on three complex projects which 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.
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 will pay 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
Get 27 Tips to Conquer the Seven Deadly
Sins of Leadership with free newsletter subscription
More Books by Lonnie Pacelli
0 Comments
Leave a Reply. |
Topics
All
Reprints
Contact Lonnie about article reprints. Please specify article you wish to reprint. Backlist
See Lonnie's Amazon Author Page Archives
September 2024
|
RSS Feed