You know and love our Must-Read IT Blogs lists, but now, say hello to the nonprofit side.
“This really shouldn’t be this hard,” I told myself as I hung up the telephone, ending the daily conference call we used for planning work activities for a project team with members around the country. I had only been the project manager for one week, but already I could tell the project team wasn’t collaborating, as it should. The physical distance and various organizational structures among team members was limiting our ability to really gel as a project team, and as a result we weren’t making the kind of progress that was expected of us.
Typically, a project team goes through four important stages as it develops: forming, storming, norming and performing. Forming, marked by polite introductions and ambiguity about roles, shouldn’t last long before members start to argue about roles and responsibilities, and storming begins. Once roles are settled and the team starts to execute, norming has started, where the daily routine is all about making progress. Performing happens when the team recognizes everyone’s skills and uses them in the best place at the best time.
My problem? After several months of development, my project team seemed, in spite of having already delivered one production release, appeared to be in the forming stage. How could this be?
As it turned out, local team members had been doing all of the real work, while remote team members had been given trivial work to do, such as smoke-testing deployments, despite their desires (and abilities) to perform more complicated technical work. As a result, they were only peripheral contributors to the project and weren’t really fully engaged, even though they wanted to be. It also meant the local project team was delivering the product through heroic efforts that included long hours and unreasonable timelines. Ironically, all of the teams had similar complaints — remote team members complained that they weren’t really involved in the project, and local team members complained about doing all of the work themselves.
I made improving collaboration across the project one of my top priorities and was determined to see substantial improvements in a very short period of time. By the start of our next iteration, I had a plan for improving collaboration and had obtained the support of all of my stakeholders in executing it. If everything went well, I would push the project team through storming and norming in no time, and we would move on to fast-paced execution as the performing phase began.
My plan revolved around three fundamentals to good collaboration, which I’ll describe in detail in the remainder of this article. Whether your team members are local or remote, you can use these principles to help them collaborate better and become a high-performing and effective team.
Teams that are still forming have difficulty discussing problems candidly. They aren’t comfortable with each other yet and aren’t sure how others will respond to criticism of the team’s performance. The comfort and trust a project team develops is built through candid discussions in which no one ends up getting hurt, even though difficult issues are discussed. As a project manager, discussing how to improve collaboration is a great way to propel a team into storming, when heated debate about roles and responsibilities can occur.
Don’t be afraid of storming — it’s a natural phase of every project team’s development, and it has to happen. Set some ground rules with the team if you need to, so everyone feels respected, but be open about the fact that you expect disagreements to occur. Then, explain your observations about collaboration in a tentative way and let the team respond. If necessary, involve everyone’s chain of command in the discussion. Let them know that collaboration needs to improve, and make it an objective of project team members and their managers to make it happen.
In my case, I took a very straightforward approach. I started off by making a list of three items that needed to improve for the project to execute at a predictable but aggressive pace. Collaboration was numbers two and three: Collaboration between the members of the technical project team was number two, and collaboration between the project team and its business partners was number three.
Discussion ensued, and agreement followed. We needed to find a better way of involving remote team members, for everyone’s sake. We agreed that our next iteration would be different, and that we would find a way to involve everyone, so we didn’t need any heroes.
One of the key behaviors that make an agile software development team successful is face-to-face communication. In-person discussion is the most effective way to share information within a project team. I felt strongly that my project team would be more effective if they could spend some time working together on the project, side by side. So, I negotiated for a travel budget, and we kicked off our next iteration with a week of peer programming in an offsite location.
The result? Better distribution of work. Everyone was involved in the design and development of the product from the beginning of the iteration, so it became easy to spread the work around since everyone had the necessary background. During one week of working together, we completed all of our design and a huge portion of construction. Once the week ended and the project teams returned to their various locations for the rest of the iteration, this collaboration continued because the team had established enough shared background to keep the project moving despite the separation. Another result was rapid progress. This working session was so effective that we have decided to kick off each iteration this way, bringing the whole team together for a week of hard-core coding.
It’s easy to lose sight of the fact that a project manager’s most important responsibility is to remove barriers to progress for the project team. Project plans, stakeholder meetings, status reports, and so forth, are all tools intended to help a project manager identify and remove roadblocks between the team and its collective goals. Unfortunately, the daily grind of managing projects can cause a project manager to lose sight of this responsibility. When this happens, collaboration suffers. Project managers who want project teams to work well together must remain focused on eliminating barriers to progress.
Distributed project teams face many challenges. New roadblocks emerged every day, and I felt personally responsible for removing them. Sometimes, it meant discussing the relative priority of work assignments with team members’ managers. Other times, it meant negotiating the scope of iterations with the business or locating funding for travel. As team members watched me resolve problems that were preventing us from moving forward, they began to express appreciation for the resulting improvements. It became clear that they felt the project was getting better and that we were making significant improvements in collaboration across the project team.
Investing a little time and energy in improving collaboration can yield huge dividends. In my case, it was the difference between a project team that struggled to deliver on time, and one that not only executed on schedule, but also made meeting deadlines look easy. A team that collaborates effectively is a joy to manage. As a project manager, it is up to you to make effective collaboration a reality.