Software projects are multifaceted endeavors that require the involvement of many, varied professional experts. When you put too many of those people in a room together, sometimes you make great progress, but many times you achieve total gridlock. Or worse, many times people from varying backgrounds and with vastly different technological understandings find it difficult, if not impossible, to find a common dialogue. Often times, projects get derailed due to improper assumptions, miscommunications, and misunderstandings.
Here are some typical problems experienced in software project communications, along with tips to boost collaboration in order to keep your project on track.
The most common communication issue in software projects stems from over-inviting. Just because people are interested in your exciting project doesn’t mean they need to be in every meeting. When there are too many people in the room, conversations derail, agendas are abandoned, and key discussion points end up getting missed.
Keep your meeting invite lists limited to key stakeholders and primary decision makers. Send out your agenda as far in advance of your meetings as possible, and clearly identify the role of each attendee that’s going to be in the room. Give careful consideration to any optional attendees; if they don’t need to be there, but they could offer valuable insight, talk to them offline before the meeting, or make a list of questions to ask them as follow-up action items.
Communications between project teams can sometimes feel like they need a translator. Business executives use different terms than marketing. And then there’s the development team – where code is a language. The underlying reality is that each team is heavily invested in their own goals. The challenge is finding a common vernacular that spans across all teams so that common messages can be shared and understood by everyone involved.
There are many techniques and tools floating around to help create a useful dialogue that is understood at every link in the software development communication chain. One of most successful is that of user story creation. User stories are single statement of narrative text that describe how one user interacts with your system in a specific manner. They are short, clear statements written in plain language that can be easily understood by anyone on the team. User story creation is a perfect example of finding a common language that reduces ambiguity and confusion and increases collaborative communication.
Managing expectations comes down to one, simple task: documenting decisions and informing anyone who needs to know those decisions were made. Many times, expectations become resentments because assumptions are made that the expectation is obvious, or that it was communicated by “someone else.”
After every meeting, be sure to send a complete list of decisions, action items, and follow-up questions to every meeting attendee. If you find that issues or items are getting dropped or forgotten, appoint a note taker for every meeting. Rotate who is taking notes so that all parties remain invested and engaged. Be sure that follow-up items receive the attention they deserve, and be sure to have your project manager monitor workloads and call out potential overload.
Many times, the identification of project risks is seen as a negative strike against a team. However, risk is a reality in any project. When risks aren’t properly identified and managed, surprises happen, and those surprises lead to schedule slips, scope creep, missed requirements, and more.
It’s important to know exactly what realities pose a risk to your project, and it’s equally important to keep managing those risks until they no longer pose a threat. Make risk management a team-wide activity by asking stakeholders and team members to bring risks to the table. Sometimes, the mere mention of a risk in a public setting can spark the right discussion to resolve the risk before it becomes a threat to scope, budget, or schedule.
When problems arise during a project, it’s tempting to find “who caused it.” However, publicly pointing fingers leads to hostile environments where all hope of collaboration dies. Once a team stops trusting one another or feels as if team members might be publicly called out for mistakes, projects suffer, and success is threatened.
When problems arise, first determine if there are issues in the environment. Were certain team members overloaded? Was there a lack of understanding in the project requirements, scope, or timeline? Were there unmanaged personality conflicts? If you can fix the environment, many times, you can resolve the issues. If there are hard conversations to be had with individuals, make sure leadership talks to those people offline and in a manner that allows them to voice their concerns and receive the feedback in a positive, helpful manner.
While it’s not advisable to call out failures publicly, it is absolutely imperative to team cohesion that successes are celebrated regularly. It’s commonly said that people always hear from others when things go exceptionally wrong. The same is true in projects. When you really project teams closely, you’ll find people going above-and-beyond every day. Yet those project champs are rarely celebrated.
Make it a point, especially during sprint retrospectives, to call out the team members who were directly responsible for project successes. Make this praise public, regular, and specific. By mentioning detailed achievements of team members, management acknowledges hard work, demonstrates their attention to the project, and fosters an environment where people feel valued. Teams who believe they are appreciated will work harder, be more open in communications, and they’ll form the cohesive, collaborative environment that breeds success.
Need a development team that champions success through positive collaboration? Give Gate6 a call. We’d love to discuss your project with you.